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CAPÍTULO 1 


Introdução 


Já existem diversos frameworks MVC no mercado e a primeira pergunta que 
você deve fazer é: existe a necessidade de aprender mais um? Em geral, exis- 
tem algumas tecnologias que, quando são escolhidas para serem usadas em 
uma aplicação, não são facilmente reversíveis. O framework MVC é uma de- 
las. 

Ele vai fazer parte de uma boa parte da sua rotina de desenvolvimento. 
Quase sempre que uma nova funcionalidade for pedida para seu projeto, além 
de implementar a regra de negócio específica, você terá que criar alguma coisa 
relativa a essa regra na camada web da sua aplicação. E aí, você mais uma vez 
estará interagindo com o framework escolhido. 

Através desse prisma, você deve ser capaz de analisar os pontos positivos 
e negativos de cada uma das suas opções e tomar a melhor decisão possível. 
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1.1 POR QUE O SPRING MVC 


O Spring é um projeto de longa data, ele ganhou muita notoriedade nos tem- 
pos em que a especificação JavaEE ainda era muito burocrática. Tirou pro- 
veito disso e tomou de assalto o mercado desde muito tempo atrás, até os dias 
de hoje. 

A ideia dele sempre foi ser uma alternativa ao JavaEE e, para atingir esse 
objetivo, eles criaram diversos projetos ao redor do módulo principal, que é 
o de injeção de dependências. 


Q Spring Framework Runtime 


AA 


Data Access/Integration Web 


JDBC ORM WebSocket Servlet 
OXM JMS 


Transactions 


Core Container 








Core Context 





Fig. 1.1: módulos do Spring 


Esse é um dos principais motivos para a adoção do Spring MVC, que é 
justamente o módulo web. Na hora da adoção de um framework, um dos 
pontos mais relevantes é o que ele lhe entrega de maneira gratuita, e o Spring 
MVC é completamente integrado com todas as extensões produzidas em cima 
do próprio Spring. Essa imagem mostra apenas as principais características 
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do framework. Para conhecer todas as opções, vale a pena acessar o link http: 
/Ispring.io/projects. 

Um outro ponto altamente relevante é o quanto de ajuda você pode obter 
através da internet. E nesse ponto, os projetos relacionados ao Spring também 
se beneficiam bastante. Eles têm uma página exclusiva com questões do Stac- 
kOverflow, apenas com as perguntas marcadas com tags relativas ao Spring. 
Você pode dar um olhada seguindo este: link http://spring.io/questions. 
Além disso, a Zero Turnaround, empresa famosa por ferramentas como o JRe- 
bel, fez um levantamento dos frameworks MVC mais usados no mercado, 
o Spring MVC liderou com 40X. Você pode dar uma olhada neste: link 
http://tinyurl.com/ng8n4zx. 


Quase zero de configuração em XML 


Atualmente, o Spring suporta que a maioria das suas configurações seja 
feita de maneira programática, ou seja, você não precisa criar nenhum XML 
para que seus módulos comecem a funcionar. Esse é mais um ponto que fa- 
cilitou ainda mais sua adoção. Em algum momento do tempo, pareceu que 
configurações em XML eram a saída para declarar informações pertinentes 
ao projeto, mas o ponto é: sempre que você altera uma dessas configurações, 
é necessário que uma nova instalação do projeto seja gerada. Dada essa con- 
dição, por que vamos deixar de escrever código em Java para escrever código 
em XML? Com uma boa separação de pacotes, conseguimos deixar nossas 
configurações bem modulares e isso será mostrado no decorrer do livro. 


1.2 Å MARGEM DA ESPECIFICAÇÃO 


As especificações produzidas pela comunidade Java são de grande valia para 
as empresas, isso é inegável. Ter uma empresa como a Oracle abalizando as 
decisões que envolvem a plataforma passa segurança para os tomadores de 
decisão que querem usar esta linguagem e suas ferramentas no seu projeto. 
O ponto negativo, assim como quase todas as decisões que tomamos, é 
que muitas vezes as especificações demoram para ser criadas e somos obriga- 
dos a recorrer a projetos de terceiros, que muitas vezes não estão integrados 
com as especificações já existentes, para concluirmos alguma tarefa. E é jus- 
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tamente aí que entra um diferencial dos projetos que usam o Spring como 
base. 

Como eles não precisam seguir as especificações, você já tem diversas op- 
ções de integrações que ainda não foram especificadas ou cujas especificações 
ainda estão imaturas. Alguns exemplos: 


* Spring Social para fazer logins sociais; 
* Quartz para integração com este agendador de tarefas; 
e Spring Data para integração com bancos de dados não relacionais; 


* Spring Security para fornecer autenticação e autorização; 


Spring Cache para ter a possibilidade de cachear diversas partes do có- 
digo. 


Essas são extensões que você pode usar nos seus projetos que tenham o 
Spring como base. Usaremos alguns deles no decorrer do livro. Vale sem- 
pre lembrar, nada impede você de tirar proveito do melhor de cada um dos 
mundos. Caso se identifique mais com um módulo da especificação do que 
com o do Spring, use-o sem medo algum. Talvez o leitor atento lembre que 
já existem especificações para agendamento e Cache, e é verdade. Elas só não 
estão tão maduras quanto as opções Open Source que já existem. 


1.3 COMECE A AVENTURA 


Durante o livro vamos construir uma aplicação muito parecida com a própria 
Casa do Código. Desenvolveremos funcionalidades que nos levarão desde os 
detalhes mais básicos do uso do Spring MVC até partes avançadas como: 


e customização de componentes de validação e conversão; 
e Caches de resultados; 
e Processamento assíncrono; 


e Testes de integração; 
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e Detalhes escondidos do processo de internacionalização. 


Fique junto comigo e leia cada capítulo com calma; eu sempre lhe direi 
se é hora de dar uma pausa ou de já pular para o próximo. Espero que você 
tenha uma grande jornada! 


1.4 PÚBLICO-ALVO 


Para pessoas que já conheçam um pouco sobre a estrutura de um projeto ba- 
seado no Design Pattern MVC. O livro vai ajudar desde pessoas que não co- 
nhecem nada do Spring MVC até usuários que já utilizam o framework na 
prática. Quase todo capítulo vai cobrir detalhes que vão além do uso normal 
e vai deixá-lo mais crítico em relação ao uso da tecnologia. 


1.5 CÓDIGO-FONTE 


Todo o código-fonte do livro está disponível no Github, basta acessar o ende- 
reço https://github.com/livrospringmvc. Fique à vontade para navegar pelos 
arquivos do projeto. Os commits foram dividos de acordo com os capítulos do 
livro, justamente para que você possa acessar o código compatível ao capítulo 
que esteja sendo lido. 


1.6 PEDINDO AJUDA 


Para facilitar a troca de ideias entre os leitores foi criado um fórum de discus- 
são específico para o livro. Basta que você acesse o endereço https://groups. 
google.com/forum/*hl=pt-BR&!forum/livro-springmvc. 


CAPÍTULO 2 


Começando o projeto 


2.1 CONFIGURAÇÃO BÁSICA E CRIAÇÃO DO PROJETO 


O objetivo do livro é construir uma aplicação semelhante a da própria Casa 
do Código. Por ser um site de e-commerce, a aplicação nos fornece a chance 
de implementar diversas funcionalidades e, além disso, é um domínio que 
não vai nos causar muitas dúvidas. 

A primeira coisa que precisamos fazer é justamente criar e configurar o 
mínimo necessário para ter nossa aplicação, com o Spring MVC, rodando 
corretamente. Como vamos usar o Maven para gerenciar as nossas depen- 
dências, somos obrigados a criar o projeto seguindo uma estrutura determi- 
nada por essa ferramenta. O layout das pastas, como de costume, vai seguir 
o seguinte formato: 
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= “e cacadocodigo 
uay dinis cimain/java 





b [Esrc/main/resources 

EE sre/test/java 

[E src/test/ resources 
& =} Maven Dependencies 
P =} JRE System Library [JavaSE-1.7] 
b = imagens-textos-livro 
T sr 

F E= main 
Y E> webapp 
[= test 

b C> target 


Mk 


Fig. 2.1: Estrutura de pastas 


Provavelmente você já deve ter feito esta atividade algumas vezes, então, 
para mudar um pouco a sua rotina, vou utilizar um modo um pouco dife- 
rente de criar o projeto. Usaremos um projeto da Red Hat chamado Jboss 
Forge, que pode ser baixado neste link http://forge.jboss.org/download. O 
Jboss Forge fornece vários comandos prontos para a criação de projetos. Após 
baixado, extraia o arquivo em uma pasta de sua preferência. Acesse o terminal 
do seu computador e digite o seguinte comando: 


$caminhoParaSuaInstalacao/bin/forge 


Isso abrirá uma aplicação no próprio console. 


Casa do Código Capítulo 2. Começando o projeto 





JBoss Forge, version [ 2.13.0.Final ] - JBoss, by Red Hat, Inc. [ http://forge.jboss.org 1 


Liavals E 


Fig. 2.2: Console do forge 


Agora basta que digitemos o comando responsável pela criação do pro- 
jeto. 


project-new --named casadocodigo 


Pronto! Isso é suficiente para você criar o seu projeto baseado no Ma- 
ven. A estrutura de pastas já está pronta, só precisamos realizar as devidas 
configurações. 


Dependências necessárias 


Precisamos adicionar todas as dependências necessárias para que seja 
possível começarmos a trabalhar no projeto. Para isso, vamos ter o arquivo 
pom. xml e adicionamos a tag <dependencies>, dentro da qual colocamos 
cada uma das dependências necessárias para começar o seu projeto usando o 
Spring MVC. 


<dependencies> 
<dependency> 
<groupld>org.springframework</groupId> 
<artifactId>spring-webmvc</artifactId> 
<version>4.1.0.RELEASE</version> 
</dependency> 


<dependency> 
<groupld>org.apache. tomcat</groupld> 
<artifactId>tomcat-servlet-api</artifactId> 
<version>7.0.30</version> 
<scope>provided</scope> 
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</dependency> 
<dependency> 
<groupld>javax.servlet. jsp</groupld> 
<artifactId>jsp-api</artifactId> 
<version>2.1</version> 
<scope>provided</scope> 
</dependency> 
<dependency> 
<groupld>javax.servlet. jsp. jstl</groupId> 
<artifactId>jstl-api</artifactId> 
<versionD>1.2</version> 
<exclusions> 
<exclusion> 
<groupld>javax.servlet</groupId> 
<artifactId>servlet-api</artifactId> 
</exclusion> 
</exclusions> 
</dependency> 
<dependency> 
<groupld>org.glassfish.web</groupld> 
<artifactId>jstl-impl</artifactId> 
<versionD>1.2</version> 
<exclusions> 
<exclusion> 
<groupld>javax.servlet</groupId> 
<artifactId>servlet-api</artifactId> 
</exclusion> 
</exclusions> 
</dependency> 
<!-- Logging --> 
<dependency> 
<groupId>org.slf4j</groupId> 
<artifactId>slf4j-api</artifactId> 
<version>1.6.1</version> 
</dependency> 
<dependency> 
<groupld>org. slf4j</groupId> 
<artifactId>jcl-over-slf4j</artifactId> 
<version>1.6.1</version> 
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<scope>runtime</scope> 

</dependency> 

<dependency> 
<groupld>org.slf4j</groupId> 
<artifactId>slf4j-10g4j12</artifactId> 
<version>1.6.1</version> 
<scope>runtime</scope> 

</dependency> 

<dependency> 
<groupId>log4j)</groupId> 
<artifactId>log4j</artifactId> 
<version>1.2.16</version> 
<scope>runtime</scope> 

</dependency> 

</dependencies> 


Perceba que foram muitas dependências e nem todas foram necessari- 
amente de projetos ligados diretamente ao Spring MVC. Não perca tempo 
analisando minuciosamente cada uma delas. Lembre-se sempre: você está 
em um projeto usando a linguagem Java; se tiver pouca dependência não tem 
graça. 

Agora que o pom. xm1 está configurado corretamente, chegou a hora de 
importá-lo para a sua ide favorita. Durante o livro, usaremos o Spring To- 
ols Suite, que é basicamente um Eclipse com alguns plugins específicos para 
projetos baseados no Spring. Caso prefira usar o seu Eclipse comum, não há 
nenhum problema. 

Vamos importar o projeto como um Maven Project; assim, para cada 
nova dependência necessária, basta alterarmos o pom.xml e o próprio 
Eclipse se encarregará de atualizar o nosso classpath. 
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Import Existing Maven Projects | - j | 





Select an import source: 
| type filter text 
> Cit 
> 6 Install 
> E=Java EE 
Y E Maven 
EI Check out Maven Projects from SCM 
E, Install or deploy an artifact to a Maven repository 
E Materialize Maven Projects from SCM 
> E Plug-in Development 
> E Remote Systems 
> © Run/Debug 
(= Spring 
> E=Tasks 
> E Team 
> E Web 
P C Web services 
> XML 











D < Back (Next> | | Cancel | — Finish 


Fig. 2.3: Tipo de importação de projeto 


Clicando no next, será exibido o wizard de importação. Basta escolher 
o caminho onde seu projeto foi criado. 
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ennea 


Maven Projects 


Import Maven Projects 





Select Maven projects 





Root Directory: | /Users/alberto/ambiente/desenvolvimento/casadocodigo X J | | Browse... 
Projects: 
J org.casadocodigo:casadocodigo:;1.0.0-SNAPSHOT:war f Select All 

| DeselectAll | 


Select Tree 
Deselect Tree 


| Refresh 


“| Add project(s) to working set 


casadocodigo 


+ Advanced 


Finish 





[ <Back )| Next> | [ Cane |) 
Fig. 2.4: Tela de importação do projeto maven 
Pronto, agora temos nosso projeto importado. O último passo é adicioná- 


lo a um servidor, para que possamos realizar nossos testes e ver como a apli- 


cação vai andando. Para isso, vamos seguir o caminho padrão de criação de 
servidores dentro do Eclipse. 
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2! problems E Console “fl Servers 33 
Kè Pivotal tc Server Developer Edition v3.0 [Stopped] 


New > E' Server 
Browse Deployment Location... 


Properties Ed] 





Fig. 2.5: Adicione um novo servidor 


WELL UIE SETVEr Lype. 





type filter text | 





YE Apache 
E Tomcat v3.2 Server 
5 Tomcat v4.0 Server 
Tomcat v4.1 Server 
B Tomcat v5.0 Server 
5 Tomcat v5.5 Server 
S Tomcat v6.0 Server 
Tomcat v7.0 Server 


= 
E Tomcat v8.0 Server 


Publishes and runs JZEE and Java EE Web projects and server configurations to a local Tomcat 














server. 

Server's host name: Y localhost | 

server name: | Tomcat v8.0 Server at localhost | 

(2) < Back | Next> | | Cancel | [Finish | 


Fig. 2.6: Escolha da versão 7 para cima 
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Tomcat Server 
Specify the installation directory 


Name: 


Apache Tomcat v8.0 


Tomcat installation directory: 








| [Users/alberto/ambiente /servidores/apache-tomcat-8.0.12 | | Browse... | 


“Download an di Install... 
JRE: 





| Workbench default JRE PI N Installed JRES... 














Fig. 2.7: Aponte o caminho de instalação 
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New r 
Open F3 
Show In XEWw > 
E Copy C 
Paste V 

X Delete > 
Rename F2 
%s Debug ED 
O Start XER 
& Profile 

fa 8 Stop NES 

2l Probl c 

pipas a EE publish XP 

Ga Pivotal tc Server [ Clean 

fa Add and Remove... 
Monitoring » 
Clean Tomcat Work Directory... 
Browse Deployment Location... 
Properties 88 | 


Fig. 2.8: Opção de adicionar projeto 
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Move resources to the right to configure them on the server 
Available: Configured: 


E casadocodigo 





< Remove 


| Add All >> 


<< Remove Al) 


M If server is started, publish changes immediately 





? < Back Next > | Cancel | [Finish] 


Fig. 2.9: Adicione o projeto ao servidor 


Para finalizarmos, vamos subir o servidor e ver se tudo funciona correta- 
mente. 
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$ in prodali bém mei rormento ant not Fauni on the javo. Tibrory path: /usersjalberto/t ibrary 


o 'org eclipse jst. jee. server icasadocodigo' dig nal Tind s matching property 









nit 
orp-apoche. coyat 
londier Thtto 


Fig. 2.10: Console indicando que o servidor subiu 


2.2 ACESSANDO O PRIMEIRO ENDEREÇO 


Com tudo configurado, chegou a hora de realmente começarmos a produzir 
alguma coisa! O nosso primeiro desafio é levar o nosso usuário para a home 
da Casa do Código. O endereço que queremos que ele digite é o /home. Em 
um cenário mais comum, a URL que leva o usuário para a home é o próprio 
/. Faremos essa alteração no final do capítulo. Neste momento, caso o usuá- 
rio digite http://localhost:8080/casadocodigo/home, ele receberá um erro do 
servidor indicando que esse endereço não pode ser atendido por ninguém. 


Respondendo a URLs 


Em geral, com o Spring MVC, assim como com quase qualquer outro 
framework MVC, sempre que quisermos responder a uma URL, teremos que 
criar uma classe responsável por isso. 


package br.com.casadocodigo.loja.controllers; 


public class HomeController { 


Apenas por convenção, é sugerido que o nome da classe termine com 
o sufixo Controller. Agora precisamos ensinar ao Spring MVC que essa 
classe, efetivamente, é responsável por atender requisições vindas de um 
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cliente, nesse caso o navegador. Para isso, vamos adicionar a annotation 
Controller nela. 


package br.com.casadocodigo.loja.controllers; 


CController 
public class HomeController { 


E como vamos fazer a lógica de carregamentos de produtos para serem 
exibidos na home? Nada mais comum do que criarmos um método. 


CController 
public class HomeController { 


public void index(){ 
//aqui ainda vamos carregar os produtos. 


Agora imagine o seguinte cenário. Você provavelmente terá diversos con- 
trollers, com as mais variadas responsabilidades e métodos. Como o Spring 
MVC vai saber qual método deve ser chamado para cada uma das URLs? É 
para isso que serve a annotation GRequestMapping: 


CController 
public class HomeController { 


ORequestMapping('/home'!) 

public void index(){ 
//aqui ainda vamos carregar os produtos. 
System.out.printin("Carregando os produtos"); 


Essa última configuração que acabamos de fazer é também conhecida 
como binding. Fizemos a ligação entre uma rota e o método responsável por 
tratá-la. O problema é que mesmo que você tente acessar o endereço agora, 
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ainda continuará recebendo o código de erro 404, indicando que o servidor 
não consegue lidar com essa URL. 


2.3 HABILITANDO O SPRING MVC 


Por mais que já tenhamos criado nosso primeiro controller, ainda não fize- 
mos nenhuma configuração para habilitar que o Spring MVC reconheça essas 
classes. Caso você puxe pela sua memória, vai lembrar que, para conseguir 
responder a URLs, em projetos web seguindo a especificação de Servlets, é 
necessário ter no mínimo um Filter ou uma Servlet configurada. E é justa- 


mente esse passo que vamos realizar a partir de agora. 


Configuração programática 


A Servlet responsável por tratar todas as requisições que chegam 
para o Spring MVC é a DispatcherServlet. Precisamos justamente dela 
para que tudo comece a funcionar. A maneira tradicional seria fa- 
zer essa configuração através do arquivo web.xml mas, como vocês 
podem ver, esse arquivo nem foi criado. Tudo será feito através de 
classes Java. A primeira tarefa é criar uma classe que seja filha de 


AbstractAnnotationConfigDispatcherServletInitializer 
package br.com.casadocodigo.loja.conf; 
//imports omitidos 


public class ServletSpringMVC extends 
AbstractAnnotationConfigDispatcherServletInitializer { 


QOverride 
protected Class<?>[] getRootConfigClasses() { 
return null; 


QOverride 
protected Class<?>[] getServletConfigClasses() { 
return null; 
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QOverride 
protected String[] getServletMappings() { 
return new Stringl] {"/"}; 


O objetivo de herdar dessa classe é justamente não ter que ficar fazendo 
o registro do DispatcherServlet na mão. Temos alguns métodos inte- 
ressantes, vamos começar pelo getServletMappings. Aqui é onde você 
diz qual é o padrão de endereço que vai ser delegado para o Servlet do Spring 
MVC. Caso fôssemos usar o web.xml, essa configuração seria equivalente 
ao <url-mapping> 

E como o Spring MVC vai saber quais controllers devem ser mapeados e 
quais outras classes devem ser carregadas pelo container do próprio Spring? 
Para essa questão, usamos o método getServletConfigClasses. Nele, 
será retornada uma ou mais classes responsáveis por indicar quais outras clas- 
ses devem ser lidas durante o carregamento da aplicação web. 


OUverride 
protected Class<?>[] getServletConfigClasses() { 
return new Class[] fAppWebConfiguration.class+; 


Agora vamos criar a classe AppWebConfiguration 


package br.com.casadocodigo.loja.conf; 


CEnableWebMvc 
CComponentScan (basePackageClasses=(HomeController.class+) 
public class ApphWebConfiguration { 


} 


Perceba que é uma classe um tanto quanto estranha. Tem um monte de 
annotation, mas nenhum código. O objetivo principal dela é expor para a 
Servlet do Spring MVC quais são as classes que devem ser lidas e carregadas. 
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Neste exato momento, a principal annotation aqui é a 
AComponentScan. Através dela indicamos quais pacotes devem ser 
lidos. Perceba que passamos como parâmetro a classe HomeController 
para que o Spring leia o pacote dela. Dessa forma, não passamos uma String 
e evitamos um possível erro de digitação. 

A annotation EnableWebMvc não é necessária agora, mas como ela já 
habilita várias funcionalidades que serão usadas na nossa aplicação web, já 
vamos deixá-la aí. Para você não ficar se perguntando quais seriam essas fun- 
cionalidades, segue uma lista com algumas delas: 


e Conversão de objetos para XML 
e Conversão de objetos para JSON 
e Validação usando a especificação 


e Suporte a geração de RSS 


Uma última observação importante é que devemos manter essas clas- 
ses em um pacote separado, focado justamente em classes que ser- 
vem apenas de configuração. Por isso estamos usando o pacote 
br.com.casadocodigo.loja.conf. 

Agora que temos tudo configurado, caso você tente acessar o endereço 
/home, infelizmente deverá receber a seguinte tela de erro. 





P Status 500 - Could not resolve view with name " in servlet with name 'dispat 





re rtp 
org. apache. toncat .vebeocket server tor doFilter|WaFíiter. javai52) 


TET the Lud stach race cf me soot caie n andando in Me Anache Trencat 0.12 bos 


Fig. 2.11: View não foi encontrada 
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2.4 CONFIGURANDO A PASTA COM AS PÁGINAS 


O erro que vimos na seção anterior indica que o Spring MVC não achou uma 
página responsável por montar o HTML relativo ao request. Puxando pela 
memória, o fluxo padrão de uma aplicação MVC é: Cliente faz request, Servlet 
principal atende e delega para um controller da aplicação e, finalmente, uma 
página é montada para responder a requisição. Por default, o Spring MVC 
segue justamente essa sequência. 

Como o retorno do nosso método é void, ele procurou por uma página 
com nome em branco e ela não foi encontrada. O primeiro passo para tentar- 
mos contornar o erro é retornar uma String, indicando o caminho da página. 


@RequestMapping("/") 

public String index(){ 
System.out.printin("Carregando os produtos"); 
return "hello-world.jsp"; 


Caso você tente acessar agora, vai receber outro erro. 





jerviet. java:1012) 
2955) 







org apr anowo: 
javax sorvlot . http. tt 
org. apache. tomcat .vobsockat 





EE The dl stack. trace cf the roct cause i availatik: mo the Apache Tomcat. 124005. 


Fig. 2.12: Exception gerada pela falta de um resolvedor de View 


O Spring MVC não sabe onde procurar por essa página, precisamos 
ensiná-lo! Para fazer isso, precisamos configurar um objeto cuja responsa- 
bilidade é informar onde as páginas devem ser encontradas. E sempre que 
falamos em configuração, pelo menos por enquanto, estamos nos referindo à 
classe AppWebConfiguration. 
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0Bean 

public InternalResourceViewResolver 
internalResourceViewResolver() { 
InternalResourceViewResolver resolver = 

new InternalResourceViewResolver(); 

resolver.setPrefix(''/WEB-INF/views/"); 
resolver. setSuffix(". jsp'); 
return resolver; 


} 


A classe InternalResourceViewResolver, como pode ser lido no 





próprio código, guarda as configurações da pasta base e do sufixo que devem 
ser adicionados para qualquer caminho que seja retornado por métodos dos 
controllers. A annotation @Bean indica para o Spring que o retorno desse 
método deve ser registrado como um objeto gerenciado pelo container. Em 
geral, no Spring, esses objetos são chamados de Beans. Para deixar tudo cor- 
reto, vamos apenas alterar o retorno do método index, do nosso primeiro 
controller. 


@Controller 
public class HomeController { 


@RequestMapping("/") 

public String index(){ 
System.out.printin("Carregando os produtos"); 
return "hello-world"; 


Agora basta que você crie uma página chamada hello-world dentro 





da pasta WEB-INF /views e tudo funcionará corretamente. 

Talvez você esteja se perguntando o motivo de deixar a página dentro da 
pasta WEB-INFE A grande sacada é você quase que obrigar os desenvolvedores 
a escreverem métodos no controller para cada funcionalidade. Desse jeito, o 
seu projeto está se protegendo de ter lógicas jogadas diretamente dentro das 
páginas. 
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2.5 UM POUCO POR DENTRO DO FRAMEWORK 


Um ponto que muitas vezes diferencia “usuários” do framework de “enten- 
dedores” é justamente ter o conhecimento do que acontece por dentro da 
ferramenta. Por exemplo, como o Spring MVC faz com que a nossa classe 
ServletSpringMvcC seja carregada? Onde está o código de carregamento 
da DispatcherServlet? Essas são perguntas que, por mais que não te- 
nham a ver com o seu código de negócio em si, podem ser importantes para 
entender algum fluxo do framework. 


O web.xml é desnecessário 


Desde a versão 3 da especificação de Servlets, justamente para facilitar a 
configuração dos frameworks, foi criado um outro tipo de arquivo chamado 
de web-fragment . xml. A ideia é que esse arquivo possa ser deixado dentro 





da pasta META-INF, no jar da biblioteca. Dessa forma, quando o servidor 
web for iniciado e a aplicação for carregada, esse arquivo vai ser lido e os ser- 
vlets ou filtros que lá estiverem serão criados e registrados dentro do servidor. 
Não por acaso, o jar do Spring MVC possui este arquivo: 


<?xml version="1.0" encoding="IS0-8859-1"2> 


<web-fragment ....> 


<name>spring web</name> 
<distributable/> 


</web-fragment> 


Analisando, ele é bem simples. Tem um nome e usa a tag 
distributable, apenas para dizer que a aplicação usando esse arquivo 
pode ser distribuída entre vários servidores. Só que, um ponto interessante é: 
onde está a configuração do servlet do Spring MVC? 


Um pouco mais a fundo na especificação 


O web-fragment é apenas para dizer que o Spring MVC pode ser noti- 
ficado sobre o início da aplicação web. Contudo, desta maneira ele ainda 
não está fazendo nada. Um outro arquivo interessante, dentro do jar, é 
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O javax.servlet .ServletContainerInitializer. Ele também fica 
dentro da pasta META-INF e o conteúdo é o que segue: 





org. springframework.web. SpringServletContainerInitializer 


Esse arquivo, especificamente com este nome, é lido pelo servidor web em 
questão e a classe configurada é carregada. 


CHandlesTypes (WebApplicationInitializer.class) 
public class SpringServletContainerInitializer implements 
ServletContainerInitializer { 


QOverride 
public void onStartup(Set<Class<?>> webAppInitializerClasses, 
ServletContext servletContext) 


throws ServletException 1 


List<WebApplicationInitializer> initializers = new 
LinkedList<WebApplicationInitializer>(); 


if (webAppInitializerClasses != null) { 
for (Class<?> waiClass : webAppInitializerClasses) { 
if (!waiClass.isInterface() &k 
!Modifier.isAbstract (waiClass.getModifiers()) && 
WebApplicationInitializer.class. 
isAssignableFrom(waiClass)) { 
try É 
initializers.add( 
(WebApplicationInitializer) 
waiClass.newInstance()); 
} 
catch (Throwable ex) { 
throw new ServletException("Failed to 
instantiate WebApplicationInitializer 
class", ex); 
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if (initializers.isEmptyO) É 
servletContext. log("No Spring 
WebApplicationInitializer types detected on 
classpath"); 
return; 


AnnotationAware0rderComparator .sort (initializers); 
servletContext.log("Spring WebApplicationInitializers 
detected on classpath: " + initializers); 


for (WebApplicationInitializer initializer 
initializers) { 
initializer.onStartup(servletContext); 


A annotation QHandlesTypes recebe como argumento um conjunto 
de interfaces, cujas classes filhas são passadas como parâmetro para o mé- 
todo onStartup. Caso você esteja curioso, verá que a nossa classe 





ServletSpringMvc é filha da interface wmebApplicationInitializer, 
justamente a que foi passada para o GHandleTypes! 


2.6 CONCLUSÃO 


Este capitulo foi um pouco longo e, para ser bem sincero, até simples. O pro- 
blema é que foi necessária muita configuração para um simples hello world. 
A parte boa dessa história é que você passou por uma das etapas mais difíceis 
no aprendizado de qualquer framework, o setup inicial. Agora tudo tende a 
ser mais fluido! Por isso, eu indico que você continue a leitura. No próximo 
capítulo já começaremos a acessar o banco de dados para cadastrar e listar os 
produtos da loja. 
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CAPÍTULO 3 


Cadastro de produtos 


Passada a fase de configuração, chegou a hora de começarmos a implementar 
algumas das funcionalidades da loja. Uma das features mais básicas, porém 
importante, é o cadastro de livros, já que sem livros não existem compras. 


3.1 FORMULÁRIO DE CADASTRO 


Vamos começar a nossa implementação justamente pela parte mais próxima 
do nosso usuário final, que é o formulário de novo produto. 


<!DOCTYPE html> 

<html> 

<head> 

<meta charset="UTF-8"> 
<title>Cadastro de produtos</title> 
</head> 


31. Formulário de cadastro Casa do Código 





<body> 


<form method="post"> 
<div> 
<label for="title'!'>Titulo</label> 
<input type="text" name="title! id="title"/> 
</div> 
<div> 
<label for="description'>Descrição</label> 
<textarea rows="10" cols="20" name="description" 
id="description"> 
</textarea> 
</div> 
<div> 
<label for="pages'">Número de paginas</label> 
<input type="text" name="pages" id="pages"/> 
</div> 
<div> 
<input type="submit" value="Enviar"> 
</div> 
</form> 


</body> 
</html> 


Não tem nada de mais, apenas um HTML normal. Só para constar, nosso 
modelo de livro não precisa ser muito complexo, tem apenas um título, des- 
crição e o número total de páginas. 

Um detalhe importante que ficou faltando: para onde vamos enviar as in- 
formações cadastradas? Ainda não criamos nada que trate essa lógica, mas já 
podemos imaginar para qual URL queremos enviar. Para isso, vamos alterar 
a declaração da tag <form> e vamos adicionar o atributo action. 


<form method="post" action="/casadocodigo/produtos!> 


Aqui vale uma observação. Foi usado o nome do contexto de maneira 
hard coded, enquanto a estratégia mais usada no mercado é o uso da tag 
<c:url>, que vem no pacote de tags padrão JSTL. O motivo dessa escolha é 
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simplesmente o da facilidade do entendimento do código. A tag, misturada 
com as aspas dos atributos das tags html, muitas vezes confundem mais que 
ajudam, pelo menos durante a leitura do livro. 

E onde vamos criar esse arquivo? A nossa configuração atual diz que de- 





vemos criar nossas views dentro da pasta WEB-INF/views. Como estamos 
lidando com o cadastro de produtos, vamos manter uma organização e criar 
uma outra subpasta, chamada produtos. O caminho final do arquivo deve 





ser WEB-INF/views/products/form. jsp. Usaremos essa tática para 
criação das próximas páginas, durante o decorrer do livro. 


3.2 LÓGICA DE CADASTRO 


Neste exato momento, se o nosso usuário tentar cadastrar um produto, ele vai 
receber o famoso erro de página não encontrada. Afinal de contas, ainda não 
criamos o controller responsável por essa funcionalidade. Vamos começar a 
resolver este problema agora. 


br.com.casadocodigo.loja.controllers; 


CController 
public class ProductsController { 


ORequestMapping(''/produtos!!) 

public String save(){ 
System.out.printin("Cadastrando o produto"); 
return "products/ok"; 


Até aqui, nada que já não tenhamos visto. Criamos um controller e um 
método, ambos com as anotações necessárias para o Spring MVC reconhecer 
o controller e também fazer o binding entre a rota e o respectivo método. E 
onde está o produto que estamos tentando cadastrar? 


Recebendo objetos como parâmetros 


Aqui não vamos ter nenhuma novidade. Todo framework que se preze 
deve permitir que o objeto seja montado e passado como parâmetro no mé- 
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todo. 


br.com.casadocodigo. loja.controllers; 


CController 
public class ProductsController 1 


ORequestMapping("/produtos!!) 

public String save(Product product) 
System.out.printin("Cadastrando o produto "+product); 
return "products/ok"; 


Não temos a classe Product, chegou a hora de criá-la: 


br.com.casadocodigo.loja.models; 
public class Product { 
private String title; 
private String description; 
private int pages; 


//getters e setters 


Perceba que os nomes dos campos do nosso formulário batem exatamente 
com os nomes dos setters que serão gerados para nós. 


e title => setTitle 


description => setDescription 


pages => setPages 


É dessa forma que o Spring MVC consegue popular o objeto em ques- 
tão. Caso você queira, adicione um toString na classe Product. Dessa 
forma, a impressão vai mostrar exatamente os valores que foram preenchidos 
no formulário. 
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URL para chegar ao formulário 


Um ponto que o leitor mais atento deve estar se perguntando é: qual é o 
endereço que o usuário vai digitar para chegar no formulário? Como a JSP 





está dentro da pasta WEB-INF, ela não está visível para ser acessada pelo lado 
de fora do servidor. 

A solução é justamente criar mais um método no controller, para levar o 
usuário para a página em questão. 


package br.com.casadocodigo.loja.controllers; 
CController 


public class ProductsController { 
//resto do código 


ORequestMapping('/produtos/form'!) 


public String form(){ 
return "products/form'"; 


O método vazio, muitas vezes, é algo que incomoda o programador. Po- 





demos até nos perguntar: por que não deixamos a JSP fora da pasta WEB-INF 
e fazemos o acesso direto? O problema dessa abordagem é que está sendo 
dada uma brecha para que alguma lógica, além da necessária para a visualiza- 
ção, seja colocada dentro da página. Um pouco mais para a frente, ainda neste 
capítulo, vamos precisar carregar os tipos de livros que podem ser vendidos. 
Caso não tivesse sido criado esse método, onde esse código seria colocado? 
Podemos dizer que esse é um mal que veio para nosso bem. 


3.3 GRAVANDO OS DADOS NO BANCO DE DADOS 


Por mais que nosso formulário já esteja um tanto quanto funcional, ainda não 
estamos efetivamente gravando as informações passadas. Para melhorar essa 
parte, vamos começar a efetuar as alterações necessárias a partir do nosso 
controller. 

A primeira coisa é começar a usar um DAO responsável pelo acesso aos 
dados referente à classe Product. 
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LEMBRETE SOBRE O DAO 


O Data Access Object é apenas uma classe cujo objetivo é isolar o 
acesso aos dados de um determinada parte do sistema. No nosso exem- 
plo, vamos precisar gravar, listar e carregar um produto. Não queremos 
misturar essa parte de acesso à infraestrutura com nossas lógicas. 











O código do método save deve ficar parecido com o que segue: 


public String save(Product product) 
productDAO. save (product) ; 
return "products/ok"; 


E de onde vem essa instância da classe Product DAO? Uma das opções é 
que a gente mesmo tenha criado esse objeto, na mão. 


private ProductDAO productDAO = new ProductDAO(); 


public String save(Product product) 
productDAO. save (product) ; 
return "products/ok"; 


O problema é que, provavelmente, o construtor do Product DAO vai pre- 
cisar receber algum objeto que represente a conexão com o banco de dados 
e, nesse caso, vamos ter que começar a controlar essas dependências na mão. 
Essa é uma Ótima parte para usarmos o Spring MVC, pois como ele é com- 
pletamente integrado com o Spring, podemos pedir que o Spring crie esse 
objeto para gente. O nosso único trabalho é indicar que precisamos receber 
injetado uma instância do Product DAO. 


public class ProductsController 1 


OAutowired 
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private ProductDAO productDAO; 


public String save(Product product)( 
productDAO. save (product); 
return "products/ok"; 


A annotation GAutowired é justamente a responsável por indicar os 
pontos de injeção dentro da sua classe. 

Nesse exato momento, nosso código não compila, já que não criamos 
ainda a classe Product DAO, assim como não existe o método save. Chegou 
a hora de resolvermos essa parte do nosso código. 


package br.com.casadocodigo.loja.daos; 


CRepository 
public class ProductDAO { 


OPersistenceContext 
private EntityManager manager; 


public void save(Product product)( 
manager .persist (product) ; 


Aqui estamos usando a JPA para realizar a parte de acesso efetivo ao nosso 
banco de dados. Na próxima seção já vamos tratar de como configurá-la. 
Voltando ao nosso ProductDAO, ela é uma classe bem normal e o único 
detalhe ao qual ficar atento é em relação ao uso da annotation ERepository. 
Para que o Spring carregue essa classe e gerencie todo seu ciclo de vida, é 
necessário que seja usada uma anotação. No nosso exemplo, estamos usando 
a GRepository, apenas para indicar que essa classe, além de ser gerenciada 
pelo Spring, é também responsável pelo acesso a dados. Existem alguns tipos 
possíveis de annotations que podemos usar quando queremos indicar que 


uma classe seja gerenciada pelo container. 
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e Component: a semântica envolvida é que essa classe é um bean do 


Spring. 
e GRespository: a classe é responsável pelo acesso a dados. 


e GController: para indicar que essa classe interage com os requests 
vindos da web. 


e GService: para indicar que a classe representa um componente inti- 
mamente ligado a alguma regra de negócio do sistema. 


O ideal é sempre usar a annotation que carrega a semântica mais próxima 
ao uso da classe. Além disso, o seu uso de forma correta ainda facilita a vida 
do Spring. Por exemplo, quando você utiliza a EController está indicando 
que os métodos da classe em questão são responsáveis por tratar requisições 
e isso faz com que eles sejam escaneados pelo Spring. 


3.4 CONFIGURANDO A JPA COM O HIBERNATE 


Estamos quase conseguindo gravar o produto, só falta agora configurarmos a 
JPA para que nosso acesso ao banco de dados fique completo. Para fazer isso, 
precisamos seguir alguns passos. 


Dependências para a JPA, Hibernate e o Mysql 


É necessário que sejam adicionadas as dependências ao arquivo 


pom.xml, dessa forma o Maven pode baixar os jars necessários. 


<project 
<dependencies> 

<!-- configuracao jpa e driver --> 

<dependency> 
<groupld>org.hibernate</groupld> 
<artifactId>hibernate-entitymanager</artifactId> 
<version>4.3.0.Final</version> 

</dependency> 
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<dependency> 
<groupld>org.hibernate</groupId> 
<artifactId>hibernate-core</artifactId> 
<version>4.3.0.Final</version> 
</dependency> 


<dependency> 
<groupld>org.hibernate. javax.persistence</groupId> 
<artifactId>hibernate-jpa-2.1-api</artifactId> 
<version>1.0.0.Final</version> 

</dependency> 


<dependency> 
<groupId>org.springframework</groupId> 
<artifactId>spring-orm</artifactId> 
<version>4.1.0.RELEASE</version> 
</dependency> 


<dependency> 
<groupld>mysql</groupId> 
<artifactId>mysql-connector-java</artifactId> 
<version>5.1.15</version> 
</dependency> 
</dependencies> 
</project> 


Como importamos nosso projeto como um Maven Project, o próprio 
eclipse já vai baixar e atualizar o nosso classpath com as novas dependências! 


Mapeando a entidade 


Com as dependências devidamente configuradas, chegou a hora de fa- 
zermos as configurações necessárias para que os objetos da classe Product 
possam ser salvos. Um passo importante é ensinar a implementação da JPA, 
nosso caso o Hibernate, que a classe Product vai representar uma tabela no 
banco de dados. 


CEntity 
public class Product { 
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OId 

CGeneratedValue(strategy = GenerationType. IDENTITY) 
private Integer id; 

private String title; 

@Lob 

private String description; 

private int pages; 


Aqui usamos algumas annotations específicas da JPA para realizar esses 


ensinamentos. 


. 
© 





Entity: indica que a classe vai virar uma tabela. 


e GITA: indica que o atributo em questão é a chave primária. 





e GGeneratedValue: indica a maneira como vai ser gerada a chave pri- 
mária. 


e @Lob: indica que o atributo em questão vai ser salvo como Clob ou 
Blob no banco de dados. 


Caso você não seja familiarizado com a JPA, fique tranquilo, vamos fi- 


car apenas no básico dela, nosso foco aqui é o Spring MVC. De todo jeito, a 


documentação do Hibernate é uma fonte de estudos. 


Isolando a configuração da JPA 


Agora, como para qualquer acesso ao banco de dados, é necessário que 


informemos algumas detalhes importantes como: 
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* Driver que deve ser usado para o acesso; 
* Login e Senha do banco de dados instalado; 
e URL de acesso ao banco; 


e Configurações da implementação da JPA. 
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Para realizar essas configurações, vamos criar uma nova na classe, no pa- 


cote br.com.casadocodigo.loja.conf. 


public class JPAConfiguration { 


CBean 
public LocalContainerEntityManagerFactoryBean 
entityManagerFactory O 
LocalContainerEntityManagerFactoryBean em = new 
LocalContainerEntityManagerFactoryBean(); 
em. setDataSource (dataSource()); 
em. setPackagesToScan(new Stringl[] 
{ "br.com. casadocodigo.loja.models! 3); 


JpaVendorAdapter vendorAdapter = 

new HibernateJpaVendorAdapter (); 
em. setJpaVendorhAdapter (vendorAdapter) ; 
em.setJpaProperties (additionalProperties()); 


return em; 


CBean 
public DataSource dataSource()1 
DriverManagerDataSource dataSource = 
new DriverManagerDataSource(); 
dataSource.setDriverClassName(''com.mysql.jdbc.Driver'); 
dataSource. setUrl( 
"jdbc:mysql://localhost:3306/casadocodigo"); 
dataSource. setUsername( "root" ); 
dataSource.setPassword( "" ); 
return dataSource; 


private Properties additionalProperties() { 
Properties properties = new Properties(); 
properties.setProperty ("hibernate .hbm2dd1.auto", 
"update"); 
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properties.setProperty ("hibernate .dialect", 

"org.hibernate.dialect.MySQL5Dialect"); 
properties.setProperty("hibernate.show sql", "true!'); 
return properties; 


Aconteceu bastante coisa nesse trecho de código, mas nada muito dife- 
rente do que você já conhece. O método dataSource () serve para con- 
figurarmos os parâmetros de conexão com o banco de dados. Você vai usar 
esse mesmo estilo de configuração mesmo que esteja usando JDBC puro, ou 
qualquer outro framework de acesso a dados. 

Já o método entityManagerFactory precisa de um pouco mais 
de carinho. Ele cria alguns objetos que são importantes para o 
nosso entendimento do que realmente está acontecendo. A classe 





LocalContainerEntityManagerFactoryBean éa abstração do arquivo 





persistence.xml, que geralmente é necessário para termos a JPA funcio- 
nando no nosso projeto. A classe HibernateJpaVendorAdapter repre- 
senta a nossa escolha de implementação da JPA que, no nosso projeto, será 
o Hibernate. O módulo de ORM do Spring suporta ainda, nativamente, o 
EclipseLink e a OpenJPA. 

A annotation @Bean, usada em cima dos métodos, é para indicar que os 
objetos criados por eles vão ser gerenciados pelo Spring e podem ser injetados 
em qualquer ponto do código. 

Agora os últimos detalhes de configuração. O primeiro é que precisamos 
informar ao servlet do Spring MVC que ele também deve carregar essa classe, 
para que todos esses métodos possam ser lidos e os objetos disponibilizados. 


public class ServletSpringMVC extends 
AbstractAnnotationConfigDispatcherServletInitializer { 


QUverride 
protected Class<?>[] getServletConfigClasses() { 
return new Class [] (AppWebConfiguration.class, 
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JPAConfiguration.class+; 


O segundo é que na AppWebConfiguration, é necessário informar que 
o pacote da classe ProductDAO deve ser lido, para que todas as classes que 
possuam alguma das annotations de componentes do Spring, possam ser car- 
regadas. 


CEnableWebMv c 

CComponentScan (basePackageClasses = { HomeController.class, 
ProductDAD.class 5) 

public class ApphebConfiguration extends WebMvcConfigurerAdaptert 


PersistenceContext 


Na classe Product DAO, para pedirmos a injeção do Entity Manager, foi 





usada a annotation GPersistenceContext. Essa annotation vem da pró- 
pria especificação JPA. Geralmente, ela é usada dentro dos servidores JavaEE, 
mas nada impede de outro framework qualquer fazer uso da mesma. Perceba 





que o nome PersistenceContext tem todo um valor semântico: ele real- 
mente indica que a classe quer receber ali um Entity Manager. Como isso vai 


ser implementado, isso é problema de cada ferramenta. 


3.5 HABILITANDO O CONTROLE TRANSACIONAL 


Caso você seja um leitor um pouco mais ansioso, já deve ter tentado gravar um 
novo produto no banco de dados e, provavelmente, não está muito contente 
com o resultado que recebeu. 
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P Status 500 - Request processing failed; nested exception is 
«persistence.TransactionRequiredException: No 





STE txceçõos report 
TEST tee eang fuder. oead exceçtar b senta cersetence Tracuectinciteca son acento: ho irecsecanas fitMansge montante 
TENTE tre secos eeronctent an tannal aere that previsted E from Safina Mis ceu 


Org, spr iogframsyork vet nt11 Mestadservitêsceptioni Request. processing failed; astad excepeion is jovar.paráistonca,TransantSontaqoirediscenttone No transact iona 
o: sja 








javax.porsistenca.TronsaotionRequiredEeception: No transactional Entitykanager availabio 
tit rCreator$SharedEnt ityManagerInvocat iongandler. invoke(SharodEnt ityMasagerCroator, java:273) 





er .cadástra(ProdatosController.java:19) 


Dol hodac 
refiect.Method, invoke (Method. 
fzamevork.vob.nathod.smppart 

ramevock .web.settod. support 








mest (TovocabloBandlecMethod. javar 112) 
taod, invokehndEandie (Servlet Invocableliandlesmothod, 
aandient aod 






Fig. 3.1: Exception por falta de um gerenciador de transações 


Como a própria exception informa, não temos ainda um EntityManager 
capaz de realizar operações transacionais. Para a nossa sorte, isso é apenas 
mais um passo que devemos configurar. Vamos adicionar mais um método e 
uma annotation na classe JPAConfiguration. 


@EnableTransactionManagement 
public class JPAConfiguration { 


@Bean 
public PlatformTransactionManager transactionManager 
(EntityManagerFactory emf){ 
JpaTransactionManager transactionManager = 
new JpaTransactionManager (); 
transactionManager .setEntityManagerFactory (emf); 
return transactionManager; 


} 


QEnableTransactionManagement é annotation que indica que agora 
vamos usar o controle transacional do Spring. 

Além de indicar que queremos o controle transacional, preci- 
samos informar por qual implementação vamos optar. A classe 
PlatformTransactionManager é justamente o ponto central do 
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Spring para esse controle. No nosso caso está sendo usada a implementação 
para a JPA. Ainda poderíamos, por exemplo, usar a implementação direta 
para o Hibernate ou até para o JDBC. 

Além desse passo, precisamos informar que os métodos da 
ProductsController precisam de transação. Para isso, basta que 
seja adicionada a annotation Gjavax.transaction.Transactional 
em cima da classe. 


CController 
OTransactional 
public class ProductsController { 





Assim como a GPersistenceContext,a ETransactional pertence 
a uma especificação do JavaEE, só que nesse caso, a JTA. 

Pronto, agora o cadastro de produtos deve estar funcionando correta- 
mente. Salve alguns produtos e depois consulte no banco de dados, para ver 
se está tudo lá! 


3.6 CONCLUSÃO 


Neste capítulo, navegamos por alguns pontos importantes do projeto. Agora 
já sabemos como receber objetos montados a partir de parâmetros do for- 
mulário, assim como vimos como realizar toda configuração necessária para 
usar a JPA dentro do nosso projeto. Caso não esteja ainda cansado, já leia o 
próximo capítulo, pois vamos incrementar o cadastro, fazer a listagem e mais 
algumas coisas. 
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CAPÍTULO 4 


Melhorando o cadastro e a 
listagem 


4.1 RECEBENDO UMA LISTA DE VALORES NO FORMU- 
LÁRIO 


O nosso formulário já faz o cadastro básico de um produto, só que na Casa 
do Código o mesmo livro pode ser vendido em formatos diferentes e a nossa 
implementação atual não suporta isso. O primeiro ponto a ser alterado é que 
nossa classe Product deve suportar uma lista de preços e seus respectivos 
formatos. 


CEntity 
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public class Product { 


CElementCollection 
private List<Price> prices = new ArrayList<Price>(); 


//getters e setters 


Agora precisamos criar a classe Price. 


package br.com.casadocodigo.loja.models; 


CEmbeddable 
public class Price { 


GColumn (scale = 2) 
private BigDecimal value; 
private BookType bookType; 


//getters e setters 


Para termos os tipos de livros bem definidos, vamos usar uma enum, no 
caso a Booktype. 


public enum BookType { 
EBOOK, PRINTED , COMBO 


Agora, se rodarmos a aplicação, por conta da criação do 
EntityManagerFactory, o nosso banco de dados já vai ser alterado 





e a nova tabela já vai ser criada. 


Modificando nosso formulário 


Com a classe já alterada, precisamos fazer as devidas modificações na pá- 
gina que contém o formulário de cadastro do produto. 


46 


Casa do Código Capítulo 4. Melhorando o cadastro e a listagem 





<hôtaglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%> 


<c:forEach items="$(types)" var="bookType' varStatus="status!!> 
<div> 
<label for="price $(bookTypej'"'>$fbookTypeJ</label> 
<input type="text" name="prices[$(status. indexj] .value" 
id="price $1fbookTypeJ"/> 
<input type="hidden" 
name="prices [$(status. indexJ] .bookType' 
value="$fbookType)''/> 
</div> 
</c:forEach> 


Dê uma respirada, já que esse pequeno trecho a mais no formulário já 
contém muita coisa. O ponto mais importante aqui é que, para passar uma 
lista de valores do formulário para o controller do Spring MVC, é necessário 
o uso do []. Usamos o atributo varStatus para conseguir ter acesso ao 
índice atual do loop e, com isso, ir construindo os inputs. Na situação atual, 
O html gerado seria como o que segue: 


<div> 


<div> 
<label for="price EBOOK">EBOOK</label> 
<input type="text" name="prices[0] .value" 
id="price EBOOK"/> 
<input type="hidden" name="prices [0] .bookType'" 
value="EBOOK"/> 
</div> 


<div> 
<label for="price PRINTED">IMPRESSO</label> 
<input type="text" name="prices[1].value" 
id="price. PRINTED"/> 
<input type="hidden" name="prices[1].bookType" 
value="IMPRESSO"/> 
</div> 
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<div> 
<label for="price COMBO">COMBO</label> 
<input type="text" name="prices[2].value" 
id="price. COMBO"/> 
<input type="hidden" name="prices [2] .bookType" 
value="COMBO"/> 
</div> 


</div> 


Como a nossa classe Product possui agora os métodos de acesso ao atri- 
buto prices,o próprio Spring MVC vai popular o nosso objeto. Essa regra 
serve para qualquer situação que você queira passar uma lista de informa- 
ções do formulário para o controller. O uso do [índice] será sempre neces- 
sário. Por exemplo, como desafio, o leitor pode fazer um método na classe 
ProductsController que receba uma lista de livros a serem cadastrados. 


4.2 DISPONIBILIZANDO OBJETOS NA VIEW 





Um ponto que talvez tenha chamado a atenção foi a realização do forEach 
sobre a variável types. Afinal de contas, onde ela foi criada e como ela foi dis- 
ponibilizada? Essa vai ser justamente uma das finalidades do método form, 
na classe ProductsController. Chegamos até a comentar, no capítulo 
anterior, que usaríamos este método para não dar a chance de nenhum usuá- 
rio chegar à página do formulário diretamente pela JSP. O argumento foi jus- 
tamente que, caso fosse necessário disponibilizar objetos para a view, seria 
melhor que esse código ficasse dentro de uma classe e não de uma página. 
Para esse tipo de tarefa, o Spring MVC oferece a classe ModelAndView. 


ORequestMapping("/form'!) 
public ModelAndView form(){ 
ModelAndView modelAndView = 
new ModelAndView('"products/form'); 
modelAndView.addObject ("types", BookType.values()); 
return modelAndView; 
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A classe ModelAndView possui métodos que nos permitem ir adicio- 
nando objetos que serão disponibilizados na view. Para quem quiser fazer o 
paralelo, por trás dos panos o Spring MVC vai pegar as chaves e valores pas- 
sados para esse objeto e repassar para o request atual, algo parecido com o 
que segue: 


Map<String,0bject> modelMap = modelAndView.getModelMap() ; 
Set<String> keys = modelMap.keySet (); 
for(String key : keys) 
Object value = modelMap.get (key); 
request.setAttribute (key, value); 


No fim das contas, é o método setAttribute que garante que os obje- 
tos estarão acessíveis na view. 

E para qual view o Spring MVC deve ir, já que agora está sendo devol- 
vido um objeto do tipo Mode lAndView? É justamente para isso que serve o 
construtor recebendo a String. 


new ModelAndView("products/form''); 


Vale lembrar que, por conta da configuração do 





InternalResourceViewResolver estamos apenas passando a pastae o 





nome da página, que estão dentro de WEB-INF /views. 
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OUTRA MANEIRA DE PASSAR OBJETOS PARA A VIEW 


Em vez de retornar um objeto do tipo ModelAndView, podemos 
receber como parâmetro do método, um objeto do tipo Model. 


public String form(Model model){ 
model .addAttribute('"types", BookType.values()); 
return "products/form"; 


Aqui é mais uma questão de gosto. Na minha opinião, retornar um 
objeto do tipo ModelAndView deixa mais claro que o método está dis- 
ponibilizando objetos para a página. 

Um outro ponto a ser observado é o recebimento desse parâmetro. 
Essa é outra possibilidade de o Spring injetar objetos nas classes. 











4.3 LISTANDO OS PRODUTOS 


Outra funcionalidade importante na Casa do Código é a de listar os livros. O 
interessante dessa implementação é que não precisaremos usar nada de novo, 
e servirá como revisão de alguns dos conceitos que foram discutidos até aqui. 

Mais uma vez, vamos começar pensando na página, que terá 
o nome de list.jsp e ficará, como já era esperado, na pasta 
WEB-INF/views/product: 





<h0 page language="java!"! contentType="text/html; charset=UTF-8" 
pageEncoding="UTF-8"Y> 
<hOtaglib uri="http://java.sun.com/jsp/jstl/core' prefix="c"y> 
<html> 
<head> 
<meta http-equiv="Content-Type' content="text/html; 
charset=UTF-8"> 
<title>Insert title here</title> 
</head> 
<body> 
<table> 
<tr> 
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<td>Titulo</td> 
<td>Valores</td> 
</tr> 
<c:forEach items="${products}" var="product"> 
<tr> 
<td>${product .title}</td> 
<td> 


<c:forEach items="$(product .prices}" 
var="price!> 
[$fprice.valuej - $fprice.bookTypeJ] 
</c:forEach> 
</td> 
</tr> 
</c:forEach> 
</table> 
</body> 
</html> 


Para o usuário chegar a essa página, terá que passar pelo nosso controller. 
Logo, já vamos criar o método responsável por isso. 


CController 

CTransactional 

public class ProductsController { 
//resto do código 


OAutowired 
private ProductDAO productDAO; 


ORequestMapping('/produtos!!) 
public ModelAndView list Of 
ModelAndView modelAndView = 
new ModelAndView("products/list''); 
model AndView.addObject ("products", productDAO.list()); 
return modelAndView; 


Agora, para esse código compilar, precisamos criar o método list na 
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classe Product DAO. 


CRepository 
public class ProductDAO { 


OPersistenceContext 
private EntityManager manager; 


public List<Product> list() { 
return manager. createQuery ("select distinct(p) from 
Product p join fetch p.prices'!,Product.class) 
.getResultList(); 


Um detalhe que o leitor mais atento pode ter notado é que os métodos 
savee list, na classe ProductsController, estão com a mesma URL. 
E agora? 


4.4 MELHOR USO DOS VERBOS HTTP 


Neste momento, caso a URL /produtos seja acessada, vamos receber a se- 
guinte exception: 


java. lang. IllegalStateException: Ambiguous mapping found.... 


O resto da exception foi ocultado, já que o começo dela diz tudo. Temos 
dois métodos tentando usar o mesmo mapeamento de URLs. Pensando bem 
nas URLs, elas até fazem sentido: 


* /produtos, para adicionar um novo produto em uma lista que já 
existe; 


* /produtos, para listar os produtos cadastrados. 


O problema aqui é que estamos deixando de usar um recurso importante 
do protocolo HTTP, os verbos. 
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* POST: usado quando existe a necessidade de criação de algum recurso; 


* GET: usado quando o interesse é o de recuperar alguma informação; 





* DELETE: como o nome diz, deve ser usado para excluir algum recurso; 














* PUT: associado com alguma operação de atualização de recursos no 
servidor. 


Estes talvez sejam os verbos mais conhecidos, com destaque para o post 
eo get. Por sinal, quando criamos uma classe que herda de HttpServlet, 
temos a opção de implementar cada um deles, separadamente. 

O verbo, junto com a URL, serve justamente para indicar o tipo de 
operação que deve ser realizada no servidor. Por exemplo, se o endereço 
/produtos for acessado através de um get, quer dizer que uma listagem 
está sendo requisitada. Caso seja acessada através de um post, está sendo 
pedido para um novo produto ser criado. Vamos ver como fica a representa- 
ção dessa teoria em nosso código: 


ORequestMapping(value="/produtos'! ,method=RequestMethod.POST) 
public String save(Product product)( 


ORequestMapping(value="/produtos' ,method=RequestMethod.GET) 
public ModelAndView list 01 


Pronto! Agora o Spring MVC vai escolher qual método deve ser usado em 
função do verbo utilizado no acesso ao endereço /produtos. Essa é uma 
ótima prática, tente sempre definir qual verbo deve ser utilizado para acessar 
cada URL do seu sistema. 
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4.5 MODULARIZAÇÃO DAS URLS DE ACESSO 


Ainda sobre os mapeamentos das nossas URLs, perceba que todos os ende- 
reços relacionados com o cadastro de produtos começam com /produtos. 


ORequestMapping('/produtos/form') 
public String form0( 
return "products/form'; 


ORequestMapping(value="/produtos!! ,method=RequestMethod.POST) 
public String save(Product product) 


ORequestMapping(value="/produtos!! ,method=RequestMethod.GET) 
public ModelAndView list(){ 


Provavelmente, esse padrão vai aparecer em diversos módulos da sua apli- 
cação e, para diminuir essa repetição, o Spring MVC permite que você anote 
um endereço base diretamente sobre a classe. 


CController 

OTransactional 
ORequestMapping(''/produtos!!) 
public class ProductsController { 


ORequestMapping("/form") 


public String form(){ 
return "products/form'"; 


ORequestMapping (method=RequestMethod.POST) 
public String save(Product product) 


ORequestMapping (method=RequestMethod.GET) 
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public ModelAndView list Of 


Perceba que agora, quando necessário, você pode colocar apenas o com- 
plemento do endereço. 


4.6 FORWARD X REDIRECT 


Agora que já inserimos e listamos, chegou a hora de melhorar um pouco 
fluxo entre essas operações. Neste momento, quando um produto é inserido, 
o usuário é levado para uma página chamada ok. jsp, que apenas indica 
que um novo livro foi cadastrado com sucesso. Nesse tipo de cenário, o fluxo 
mais indicado é voltar com o usuário para a listagem, talvez mostrando uma 


mensagem de sucesso. 


ORequestMapping (method=RequestMethod.POST) 
public ModelAndView save (Product product) 
productDAO. save (product) ; 
return list(); 


Esse código implementa justamente o fluxo sugerido. Quando acabamos 
de salvar um novo produto, invocamos o método lista, que é o responsá- 
vel por listar os produtos e jogá-los para a página product s/list.jsp. O 
ponto negativo dessa solução é que o endereço que fica na barra do navega- 
dor ainda é o último acessado pelo usuário, que nesse caso foium post para 
/produtos. Caso o nosso cliente aperte um F'5, o navegador vai tentar re- 
fazer a última operação, causando uma nova inserção de produto no sistema. 
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e c localhost: 8080 /casadocodigo/ produtos ú E 
Titulo Valores Confirm Form Resubmission 
Rails [15/00 - EBOOK] [25.00 - IMPRESSO] [3500 -C 


Play [10,00 - EBOOK] (20.00 - IMPRESSO) [25,00 - C es page nha vã rres beroe cg e a á 
Django [5/00 - EBOOK] [10,00 - IMPRESSO) (12.56 - CÊ Dove vareta rantaa Sause aty action you took to De repeat 
Django [5.00 - EBOOK] [10,00 - IMPRESSO) [12.56 - CC 

scala [30.00 - EBOOK] [40.00 - IMPRESSO] [65.00 - C 

scala [30.00 - EBOOK] [40.00 - IMPRESSO] [65.00 - C 

scala [30.00 - EBOOK) [40.00 - IMPRESSO] [65.00 - COMBOY 

scala [30.00 - EBOOK] [40,00 - IMPRESSO] [68,00 - COMBO] 

scala [30.00 - EBOOK) [40.00 - IMPRESSO) [65.00 - COMBO] 

scala [30.00 - EBOOK) [40.00 - IMPRESSO) [68,00 - COMBO] 

scala [30.00 - EBOOK] [40/00 - IMPRESSO] [65,00 - COMBO] 

scala [30.00 - EBOOK! 140.00 - IMPRESSO! [65.00 - COMBO! 






Continse 


Fig. 4.1: Problema do forward depois de um post 


Observe que o próprio navegador percebe que tem algo de estranho e 
pergunta se você tem certeza de que quer reenviar os dados. Essa técnica de 
redirecionamento que acontece apenas do lado do servidor é o que chama- 
mos, no mundo Java, de forward. O browser nem sabe o que aconteceu, tanto 
que, se olharmos no console do Chrome, ele só vai identificar um request. 


Fig. 4.2: Chrome tools indica apenas um request 


É considerada uma má prática realizar um forward após o usuário ter 
feito um post, justamente por conta do problema da atualização. Para esse 
cenário, a melhor solução é forçar o usuário a fazer uma nova requisição para 
a nossa listagem e, dessa forma, permitir que ele atualize a página sem que 
um novo post seja realizado. 


ORequestMapping (method=RequestMethod.POST) 
public String save(Product product) 
productDAO. save (product); 
return "redirect :produtos"; 


O prefixo redirect: indica para o Spring MVC que, em vez de sim- 
plesmente fazer um forward, é necessário que ele retorne o status 302 para o 
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navegador, solicitando que o mesmo faça um novo request para o novo ende- 
reço. 


© O Y Žž Preserve log Disable cache 


Name 
Path 


x Prenu ” r 
|http://localhost:8080/casadocodigo/ produtos |""eview Response Cookies Timing 
[—— Remote Address: [::1]:B080 
Request URL: http://localhost: B080/casadocodigo/produtos 
] produtos Request Method: POST 
<> i Status Code: « 302 Found 
Ei > Request Headers (12) 
+ Form Data (9) 
y Response Headers view source 
Content-Language: en-US 
Content-Length: 0 
Date: Tue, 20 Jan 2015 14:31:30 GMT 


Location: http://localhost:8080/casadocodigo/produtos 
Server: Apache-Coyote/1.1 


Fig. 4.3: Chrome tools indica dois requests 


Perceba que entre os cabeçalhos contidos na resposta existe um chamado 
Location, que informa justamente qual é o endereço ao qual o navegador deve 
fazer a próxima requisição. Essa técnica, onde fazemos um redirect do lado 
do cliente logo após um post, é um padrão conhecido da web chamado de 
Always Redirect After Post e deve ser sempre utilizado. 


4.7 PARÂMETROS EXTRAS NOS REDIRECTS 


Ainda sobre o nosso redirect, geralmente é necessário que indiquemos para 
o usuário que realmente tudo ocorreu bem. Isso é feito exibindo uma men- 
sagem de sucesso para o cliente em questão. 


Uma das maneiras de realizar essa tarefa é utilizando algumas classes que 
já estudamos. 


ORequestMapping (method=RequestMethod.POST) 
public ModelAndView save (Product product) 
productDAO. save (product) ; 
ModelAndView modelAndView = 
new ModelAndView(''redirect:produtos''); 
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modelAndView.addObject ("sucesso!", 
"Produto cadastrado com sucesso"); 
return model AndView; 


Como o endereço passado para o ModelAndView contém um redirect, 
o próprio Spring MVC vai pegar os objetos adicionados e passá-los como ar- 
gumentos da URL /produtos. 


http://localhost :8080/casadocodigo/produtos? 
sucesso=Produto+cadastrado+com+sucesso 


Essa técnica funciona tranquilamente, mas um dos medos dos desenvol- 
vedores é que algum cliente possa alterar a URL e causar algum dano para 
o sistema. Outra questão é que os objetos adicionados no ModelAndView 
para um redirect, só podem ser do tipo String. O motivo é que, como já mos- 
tramos, eles serão usados como parâmetros da URL. 

Outra maneira de passarmos esses objetos é guardando-os na sessão do 
usuário. O problema é que esses objetos serão mantidos enquanto nosso usuá- 
rio estiver ativo na aplicação e, na nossa situação, queremos apenas que eles 
sejam mantidos até o próximo request. Foi justamente para este tipo de cená- 
rio que criaram um novo escopo dentro dos frameworks, chamado de flash. 


@RequestMapping (method=RequestMethod.POST) 
public String save(Product product, 
RedirectAttributes redirectAttributes){ 
productDAO. save (product) ; 
redirectAttributes.addFlashAttribute('"sucesso", 
"Produto cadastrado com sucesso"); 
return "redirect :produtos"; 


A classe RedirectAttributes é justamente a responsável por isso. 
Todo objeto adicionado nela, através do método addFlashAttribute, fi- 
cará disponível até o próximo request, sendo acessível de maneira simples 
através da Expression Language. 


${sucesso} 


58 


Casa do Código Capítulo 4. Melhorando o cadastro e a listagem 





4.8 CONCLUSÃO 


Neste capítulo, estudamos mais detalhes sobre como o Spring MVC lida com 
os formulários. Além disso, vimos como podemos ser mais específicos em re- 
lação às nossas URLs, usando os verbos. Para fechar, deixamos nossos ende- 
reços mais modulares e ainda discutimos forwards e redirects, inclusive vendo 
como funciona a passagem de objetos para os dois modelos de redireciona- 


mentos. 
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CAPÍTULO 5 


Validação e conversão de dados 


O nosso cadastro já está funcional, mas estamos deixando de fazer uma coisa 
básica: validar os dados de entrada. Neste momento, caso um usuário queira 
cadastrar um novo livro, ele tem a opção de deixar todos os campos em 


branco. 


5.1 VALIDAÇÃO BÁSICA 


A primeira opção de solução para essa situação é escrever o código de valida- 
ção dentro do próprio método save, da classe ProductsController. 


ORequestMapping (method=RequestMethod.POST) 
public String save(Product product, 
RedirectAttributes redirectAttributes)( 


if (StringUtils.isEmpty (product .getTitle())){ 
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//adiciona erro de validação 

} 

if (StringUtils.isEmpty (product .getDescription())){ 
//adiciona erro de validação 


productDAO. save (product) ; 

redirectAttributes.addFlashAttribute("sucesso", 
"Produto cadastrado com sucesso"); 

return "redirect :produtos"; 


A lógica não tem nada de nada de complicado, na verdade deve ser bem 
parecida com várias que o leitor já presenciou. Um ponto negativo dessa solu- 
ção é que o controller, que idealmente deveria apenas ficar chamando lógicas 
do sistema e controlando qual é o próximo de navegação, agora também está 
responsável pelo código de validação. Uma outra questão é que o objeto do 
tipo Product pode ser validado em outros lugares do sistema, por exemplo 
na funcionalidade de salvar vários livros de uma vez. Para contornarmos essas 
situações, podemos deixar a lógica de validação em uma outra classe, espe- 
cializada apenas para isso. E como essa é uma funcionalidade requerida em 
várias aplicações, o Spring já possui um módulo focado apenas em validação, 


vamos começar a usá-lo. 

package br.com.casadocodigo.loja.validation; 

import org.springframework.validation.Validator; 
public class ProductValidator implements Validator{ 


@Override 
public void validate(Object target, Errors errors) { 
ValidationUtils.rejectIfEmptyOrWhitespace(errors, 
"title", "field.required'"'); 
ValidationUtils.rejectIfEmptyOrWhitespace(errors, 
"description", "'field.required"); 


Product product = (Product) target; 
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if (product .getPages() == 0) 
errors.rejectValue("pages", "field.required"); 


A regra de validação permanece basicamente a mesma, o mais interes- 
sante é a parte que o Spring nos fornece. Primeiramente implementamos a 
interface Validator, que nos obriga a escrever dois métodos: 


* supports: analisaremos esse método em alguns minutos. 


e validate: responsável pela validação em si. 


O método validate recebe como argumento o objeto a ser validado, 
no caso especificado pelo parâmetro target e um outro objeto do tipo 
Errors, onde vamos guardando cada uma das falhas de validação. A classe 





ValidationUtils é um helper do Spring Validation para realizar algumas 
validações básicas. Aqui é interessante analisar a assinatura dos métodos que 


começam com reject. 


public static void rejectIfEmpty(Errors errors, String field, 
String errorCode) {....} 


e Errors errors: objeto onde será guardado cada um dos erros de 





validação. 


* String field: representa o atributo do modelo que deve ser vali- 
dado. 


e String errorCode: chave que será usada para buscarmos a mensa- 


gem relativa a esse erro. 


Um detalhe importante em relação ao parâmetro field é que, por exem- 
plo, se quisermos validar o estado dos objetos do tipo Price, da nossa 
classe Product, teríamos que usar a seguinte sintaxe: price.value. Isso 


63 


5.1. Validação básica Casa do Código 





vale para outros casos também. Se for necessário validar as informações 
de endereço de uma classe Usuario, provavelmente seria passada a String 
endereco. rua e assim por diante. 

Para fechar, caso seja preciso fazer uma lógica de validação que não exista 
na classe utilitária, pode ser usado o método rejectValue para adicionar 





a mensagem na lista de erros. Esse método é da própria classe Errors. 


public class ProductValidator implements Validatort 


QUverride 
public void validate(Object target, Errors errors) { 


Product product = (Product)target; 
if (product .getPages() == 0) 
errors.rejectValue("pages", "field.required"); 


Na verdade, isso é o que é feito dentro dos métodos da classe 
ValidationUtils. 


Configurando a validação no Controller 


Agora que temos nossa classe responsável pela validação de objetos do 
tipo Product, precisamos pedir para o Spring MVC fazer uso dela, no mo- 
mento da construção do objeto com os dados vindos do formulário. 


ORequestMapping (method=RequestMethod.POST) 
public String save(0Valid Product product, 
RedirectAttributes redirectAttributes)( 


A annotation @Valid vem da especificação Bean Validation, e é 
utilizada por diversos frameworks para indicar o disparo do processo de va- 
lidação. Agora, um pensamento importante: como o Spring MVC vai saber 
que é para usar a classe ProductValidator para validar o objeto do tipo 
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Product? Para resolver isso vamos falar para o Spring MVC qual validator 
ele deve usar. 


CController 

OTransactional 
ORequestMapping('/produtos!!) 
public class ProductsController { 


OInitBinder 
protected void initBinder (WebDataBinder binder) 1 
binder.setValidator (new ProductValidator ()); 


A annotation QInitBinder indica que esse método deve ser chamado 
sempre que um request cair no controller em questão. O nome do método 
não é importante, pode ser qualquer um. O importante é que você recebe um 
objeto do tipo WebDataBinder e, com ele, é possível registrar novos vali- 
dators. A linha binder.setValidator (new ProductValidator ()); 
mostra exatamente essa opção. Através desse objeto, também podemos adici- 
onar novos conversores de tipos e informar quais campos podem ser enviados 
pelo formulário, entre outras coisas. 

Para esse código já ficar funcional, precisamos adicionar as dependências 
necessárias para podermos usar a Bean Validation. No nosso caso, vamos usar 
o Hibernate Validator como escolha de implementação dessa especificação. 


<!-- JSR 303 with Hibernate Validator --> 

<dependency> 
<groupIĪId>javax.validation</groupId> 
<artifactId>validation-api</artifactId> 
<version>1.0.0.GA</version> 

</dependency> 

<dependency> 
<groupId>org.hibernate</groupId> 
<artifactId>hibernate-validator</artifactId> 
<version>4.1.0.Final</version> 

</dependency> 
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Uma última informação relevante: adicionamos o ProductValidator 
como sendo o validador que será utilizado para qualquer formulário que en- 
volva o cadastro de novos livros. O ponto aqui é: podem existir situações em 
que o formulário seja um pouco diferente e, aí, não vamos ter uma associação 
tão direta com nossa classe de modelo. Nessas ocasiões, uma estratégia é criar 
uma outra classe que represente justamente esse formulário. 


public class UpdateProductForm { 
// atributos que podem não existir na classe Product. 


Poderia ser criado um validator específico para este formulário. 


public class UpdateProductFormValidator implements Validatort 


Por fim, você adicionaria mais esse validador no WebDataBinder, ano- 
taria o parâmetro do método com @valide o Spring MVC poderia utilizá-lo. 
Só que a pergunta é: como o framework vai saber que para determinado pa- 
râmetro ele deve usar um validador e que, para outro parâmetro, ele deve usar 
outro? A resposta é o método supports, que também deve ser implemen- 
tado dentro da classe que implementa a interface Validator. 


public class ProductValidator implements Validatort 


QUverride 
public boolean supports(Class<?> clazz) { 
return Product.class.isAssignableFrom(clazz); 


Esse método recebe a classe do objeto que está querendo ser validado e 
retorna se o validador consegue lidar com ele. Essa é a forma como o Spring 
MVC controla qual validação deve ser aplicada. Inclusive, é uma ótima ma- 
neira de separar regras de validação em várias classes e deixar que o Spring 
MVC execute cada uma delas para você. 
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Uma curiosidade sobre o uso das validações customizadas do Spring: 
caso você associe uma classe de validação a um controller, mas seu método 
supports não aceite o parâmetro anotado com @Valid, será lançada uma 
exception parecida com a que segue. 


java. lang. IllegalStateException: Invalid target for Validator 
br.com.casadocodigo.loja.validacao.ProductValidator 


Voltando para a tela de erro 


Com a validação básica configurada, não é mais permitido que façamos 
o cadastro de um produto com dados inválidos. O problema é que a tela de 
erro, neste momento, não é muito amigável. 


TENTE The coque sent ty the ciont sas mocacicady come. 


Fig. 5.1: Status de request inválido 


O código de erro 400 indica que a requisição foi executada com dados 
inválidos. Entretanto, nosso usuário não entende nada disso, o que ele quer é 
voltar para a tela de formulário, para preencher os campos devidamente. 


ORequestMapping (method=RequestMethod.POST) 
public String save(QValid Product product, 
BindingResult bindingResult, 
RedirectAttributes redirectAttributes)( 
if (bindingResult .hasErrors()){ 
return "produtos/form'"; 
} 
productDAO. save (product); 
redirectAttributes.addFlashAttribute('"sucesso!", 
"Produto cadastrado com sucesso"); 
return "redirect:produtos"; 


[a] 
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Para conseguirmos verificar se o formulário teve erro ou não, fazemos 
uso do objeto do tipo BindingResult. Essa classe possui vários métodos, 
tanto para verificar se existem erros de validação, quanto para acrescentar 
novos erros, caso o programador queira efetuar alguma lógica de validação 
diretamente no método do controller. 


Reaproveitando métodos no controller 


Ainda precisamos completar nosso fluxo, já que os dados enviados pelo 
usuário não estão sendo mostrados no formulário, após a validação. Além 
disso, ainda temos outro problema, os campos de preços por tipo de livro não 
estão mais sendo exibidos. O problema é que a gente retorna o usuário para 
o formulário, mas não adiciona no ModelAndView os tipos de livros. Para 
resolver isso, podemos fazer uma leve modificação no método save, para 
que seja possível reaproveitar a lógica do método form. 


ORequestMapping (method=RequestMethod.POST) 
public ModelAndView save(QValid Product product, 
BindingResult bindingResult, 
RedirectAttributes redirectAttributes)( 
if (bindingResult .hasErrors (0) 
return form(); 


} 

productDAO. save (product) ; 

redirectAttributes.addFlashAttribute("sucesso", 
"Produto cadastrado com sucesso"); 

return new ModelAndView("redirect:produtos"); 


Agora, caso seja encontrado algum erro de validação, é retornado o objeto 
do tipo ModelAndView criado pelo método form, que já é responsável por 
disponibilizar os tipos de livro na view. Caso tudo tenha ocorrido bem, é 
retornado um ModelAndView com a String de redirect para URL de listagem 
de produtos. 


68 


Casa do Código Capítulo 5. Validação e conversão de dados 





5.2 EXIBINDO OS ERROS 


Nosso usuário, após um problema de validação, já é retornado para o formu- 
lário inicial. Só que ainda não mostramos os erros e nem estamos mantendo 
os dados preenchidos por ele. Esses são dois problemas que precisam ser re- 
solvidos. 

Vamos começar pela exibição dos erros na página. Sempre que algum erro 
acontece, o Spring MVC disponibiliza um objeto do tipo BindingResult 
para a JSP, contendo todas as informações necessárias. Lembre-se que esse 
objeto é o mesmo que usamos no método do controller para verificar se foram 
encontrados erros de validação. 


<hôtaglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%> 


<c:forEach 
items="$(requestScope[ºorg.springframework.validation. 
BindingResult.product”].allErrorsy var="error''> 


$ferror.codej<br/> 


</c:forEach> 





O método allErrors retorna uma lista de objetos do tipo 





FieldError, o qual possui as informações relevantes sobre cada pro- 
blema encontrado no processo de validação. 

Essa maneira de exibir os errors até funciona, o único problema dela é o 
nome horrível da variável. Isso é uma decisão interna do framework e, em 
geral, esse tipo de coisa pode mudar facilmente, até de um update para outro. 
Dessa forma, não é bom basear qualquer código da nossa aplicação em uma 
String como essa. 


Usando a tag hasBindErrors 


Para facilitar a exibição das mesmas mensagens de erro, podemos usar 
uma taglib fornecida pelo Spring MVC. 
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<h0 taglib prefix="spring" 
uri="http://www.springframework.org/tags"y> 


<spring:hasBindErrors name="product"> 
<ul> 
<c:forEach var="error" items="$ferrors.allErrors+'> 
<li>$ferror.codeJ</1li> 
</c:forEach> 
</ul> 
</spring:hasBindErrors> 


A tag hasBindErrors disponibiliza o mesmo objeto do tipo 





BindingResult para você, só que agora sob a variável errors. A van- 
tagem é que o código não fica acoplado com uma String criada dentro do fra- 
mework. Ela ainda possui o atributo name que, curiosamente, recebeu como 
argumento a String produto. Todos os erros de validação ou conversão, 
capturados pelo processo Spring MVC, são associados a algum parâmetro 


em questão. 


public String save(OValid Product product,...){ 


No caso do método save o tipo do parâmetro é Product e, exatamente 
por isso, passamos uma String de mesmo nome, com a primeira letra em mi- 
núsculo, para o atributo name, da tag. Isso é muito importante, pois caso o 
método possua outros parâmetros que devam ser validados, os erros de cada 
um ficarão disponíveis associados ao tipo do mesmo parâmetro. Para ficar 
ainda mais claro, vamos lembrar do primeiro código utilizado para exibir os 
problemas de validação. 


<c:forEach 
items="$(requestScope[ºorg.springframework.validation. 
BindingResult .product”] .allErrorsy var="error"> 
${error .code}<br/> 


</c:forEach> 
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Perceba que a variável acaba com .product e é justamente essa mesma 
variável que será usada internamente pela tag. Para o leitor mais curioso, 
segue o trecho de código da tag do Spring MVC responsável por isso. 


public class RequestContext { 


public Errors getErrors(String name, boolean htmlEscape) { 
Errors errors = this.errorsMap.get (name); 
boolean put = false; 
if (errors == null) { 
errors = (Errors) getModelObject( 
BindingResult.MODEL KEY PREFIX + name); 
// Check old BindException prefix for backwards 
// compatibility. 
if (errors instanceof BindException) { 
errors = 


((BindException) errors) .getBindingResult (); 





A tag hasBindErrors faz parte do conjunto de tags sob a URI http: 
/Iwww.springframework.org/tags. Esse mesmo namespace ainda possui di- 
versas outras tags que podem ser úteis para sua aplicação. Alguns exemplos: 


* message: uma extensão da tag de mensagens padrão, que existe na 
JSTL. 


e transform: para aplicar conversões de tipos especificos para String. 
* url: uma extensão da tag URL padrão, que existe na JSTL 


e mvcUrl: função que ajuda a referenciar as URLs dos métodos dentro 
da JSP. 


A função mvcUrl merece uma atenção especial, pois vai nos ajudar a 
contornar um problema que já estamos enfrentando. Até agora, na action do 
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formulário de cadastro, para referenciarmos o endereço que leva até o método 
de cadastro, foi usada a URL completa. 


/casadocodigo/produtos 


Isso até funciona, mas temos dois problemas: 


* caso o nome do contexto mude, temos que mudar a URL; 


* caso a URL mude, seremos obrigados a mudar em todos lugares. 


Para resolver os dois casos, existe a função mvcUrl. 


<form action="$(spring:mvcUrl ("PCtsave'!) .build()J"! method="post'> 


Essa função recebe como parâmetro as letras em maiúsculo do seu con- 
troller e o nome do método, separados pelo #. O método build () serve 
para realizar a construção da URL. A saída ficaria assim: 


http://localhost :8080/casadocodigo/produtos 


A vantagem é que, caso você queira mudar a URL do seu controller, 
você não precisará mudar os links da sua página. Para finalizar, se você não 
gostar da sintaxe com o +, é possível usar o atributo name da annotation 
ARequestMapping e definir um nome para ser usado dentro da função. 


ORequestMapping (method=RequestMethod.POST,name="saveProduct!') 
public ModelAndView save(....) 


Agora, quando a função mvcUrl for utilizada, ela pode receber como ar- 
gumento o valor passado para o atributo name da annotation. 


$fspring:mvcUrl ("saveProduct") .build()+ 
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5.3 EXIBINDO AS MENSAGENS DE ERRO DE MANEIRA 
AMIGÁVEL 


Por mais que o formulário esteja sendo validado, as mensagens de erro ainda 
não dizem muita coisa sobre o problema em questão. Atualmente, o máximo 
que podemos conseguir é exibir os erros da seguinte forma: 


numeroPaginas - typeMismatch 
titulo - field.required 
descricao - field.required 
numeroPaginas - field.required 


Apenas para não ficar dúvidas, a mensagem typeMismat ch indica que 
aconteceu um problema de conversão. Nesse caso o motivo é que o campo 
número de páginas foi deixado em branco e no modelo Product, ele é um 
atributo do tipo int. 

Para resolver esse problema precisamos ensinar ao Spring MVC onde ele 
deve buscar as mensagens corretas e, para isso, vamos criar um arquivo ex- 
terno contendo as mesmas. Vamos dar uma olhada no conteúdo dele. 


field.required = Campo obrigatorio 
field.required.product.title = Titulo obrigatorio 


Aqui configuramos uma mensagem padrão para a chave 
field.required e ainda optamos por deixar uma específica para o 
título do produto em questão, field.required.product.title 





Esse arquivo deve ser criado dentro da sua pasta WEB-INF e geralmente é 
chamado de messages. properties. Agora é necessário avisar ao Spring 
MVC que ele deve usá-lo para buscar as mensagens relativas às chaves que 
estão configuradas. Para isso, vamos adicionar um novo método na classe 


AppWebConfiguration. 


CBean 
public MessageSource messageSource (1 
ReloadableResourceBundleMessageSource bundle = 
new ReloadableResourceBundleMessageSource() ; 
bundle.setBasename('/WEB-INF/messages''); 
bundle.setDefaultEncoding("UTF-8"); 
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bundle. setCacheSeconds (1); 
return bundle; 


Perceba que indicamos a localização do arquivo base de mensagens. Mais 
para a frente, vamos voltar a utilizá-lo para fazer nossa aplicação suportar vá- 
rios idiomas. Um método interessante é o setCacheSeconds. Ele serve 
para indicar que o arquivo de mensagens deve ser recarregado a cada inter- 
valo de tempo, no caso, foi configurado apenas um segundo. Essa é uma con- 
figuração típica de ambiente de desenvolvimento, já que não queremos ficar 
parando e subindo o servidor a cada alteração desse arquivo. 

Um detalhe muito importante, mas não muito claro, é que o nome do 
método deve ser messageSource. O Spring MVC vai procurar por um 
Bean registrado com esse nome, para que possa carregar as mensagens. Uma 
alternativa, para não ter que se preocupar com o nome do método, é utilizar 


o atributo name da annotation GBean. 


Bean (name="messageSource!!) 
public MessageSource loadBundle ()1 


Na opinião deste autor não existe um melhor que o outro. Até porque você 
não fica alterando o nome dos métodos de configuração. Não perca tempo 
com isso, apenas faça a configuração necessária para que você possa continuar 
o desenvolvimento da da aplicação. 

Agora, finalmente, estamos prontos para exibir as mensagens dentro da 
nossa página. 


<spring:hasBindErrors name="product'> 
<ul> 
<c:forEach var="error'" items="$ferrors.allErrors+!'> 
<li><spring:message code="$ferror.code)" 
text="$ferror.defaultMessage)"/></1i> 
</c:forEach> 
</ul> 
</spring:hasBindErrors> 
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A tag message, como mostramos, serve para buscar as mensagens asso- 
ciadas às chaves. O atributo text nos ajuda a deixar uma mensagem padrão 
onde as chaves ainda não estiverem configuradas no arquivo. 


Alterando a mensagem de conversão 


Voltando um pouco para os problemas de validação, um outro erro que 
pode existir no formulário de cadastro é a entrada de um valor não condi- 
zente com o tipo do campo. Por exemplo, um usuário pode digitar “dez” em 
vez de “io” no campo de número de páginas. Esse tipo de situação também 
acontece, em geral, com campos de datas. Para exibir mensagens amigáveis, 
relativas aos erros de conversão, adicionamos as chaves que começam com 


typeMismatch. 


field.required = Campo obrigatorio 
field.required.product.title = Titulo obrigatorio 
typeMismatch.product.pages = Digite um número, exemplo "100" 
typeMismatch.java.lang. Integer = Digite apenas números 
typeMismatch.int = Digite apenas numeros 

typeMismatch = O tipo esta errado 


Perceba que adicionamos as mensagens para problemas de conversão de 
tipos inteiros no geral e ainda indicamos uma mais específica para o atributo 


pages. 


Posicionamento da mensagem de erro 


As mensagens de erros estão sendo exibidas no início da nossa tela, mas 
não é incomum que o cliente requisite que a mesma mensagem seja exibida 
ao lado do campo. E é justamente o que vamos fazer agora. 


<spring:hasBindErrors name="product'"> 


<form action="$(spring:mvcUrl ("PCtsave') .buildO 
method="post'"> 
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<div> 
<label for="title"!'>Titulo</label> 
<input type="text" name="title" 
id="title" /> 
<c:forEach var="error" 
items="$ferrors.getFieldErrors(ºtitle?)+!> 
<span> 
<spring:message code="$ferror. codes 
text="$(error.defaultMessage)"/> 
</span> 
</c:forEach> 
</div> 


</form> 
</spring:hasBindErrors> 


Fizemos uma pequena modificação e deixamos o formulário inteiro den- 
tro da tag hasBinderrors. Com essa alteração, podemos usar a variá- 
vel errors do lado de cada campo dele e neste caso foi usado o método 





getFieldErrors para pegar o erro de cada atributo. 

O único problema desse código é que ele provavelmente será necessário 
em várias páginas do nosso sistema. Para não termos que ficar copiando e 
colando esse código, vamos utilizar uma outra tag provida pelo Spring MVC. 


<h0 taglib prefix="spring" 
uri="http://www.springframework.org/tags"Wk> 

<%0 taglib prefix="form" 
uri="http://www.springframework.org/tags/form"y> 


<form:form action="$(spring:mvcUrl ("PCtsave"') .build()" 
method="post" 
commandName="product"> 


<div> 
<label for="title">Titulo</label> 
<input type="text" name="title" id="title"/> 
<form:errors path="title"/> 

</div> 
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</form: form> 


O código ficou muito mais legível! A tag errors faz praticamente o 
mesmo papel do nosso código anterior. Ela vai exibir todos os erros do atri- 
buto em questão. Ela ainda possui alguns atributos para que você possa defi- 
nir, entre outras coisas, o estilo e a tag HTML que vai ser utilizada para ren- 
derizar os erros. Para que a tag errors funcione, é necessário que ela seja 
usada dentro da tag form. 


<form:form action="$(spring:mvcUrl ("PCfsave") .build(O)" 
method="post" 
commandName="product"> 


<form:errors path="title"/> 
</form: form> 


O ponto que precisa de mais atenção na tag form é o atributo 
commandName. Ele tem o mesmo propósito do atributo name na tag 





hasBindErrors, ou seja, recebe o tipo do parâmetro que está sendo vali- 
dado pelo nosso controller, com a primeira letra em minúsculo. Apenas para 


refrescar a memória: 


save(QValid Product product....) 


Um último detalhe, foi necessário importar mais um conjunto de tags 


para a nossa página. 


<h0 taglib uri="http://www.springframework.org/tags/form" 
prefix="form"y> 


Esse conjunto possui tags que nos ajudam a escrever um formulário em 
si. Seguem alguns exemplos: 


e checkbox 
e select 


e hidden 
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e form 


Na próxima seção já vamos fazer um pouco mais de uso dessas tags. 


5.4 MANTENDO OS VALORES NO FORMULÁRIO 


Para completar nosso formulário, precisamos dar a possibilidade de o usuário 
continuar o preenchimento de onde ele parou. Atualmente, caso aconteça 
algum erro de validação, voltamos para a mesma tela, mas não mantemos as 
informações previamente preenchidas. Vamos ver como o Spring MVC pode 
nos ajudar. 


<form:form action="$(spring:mvcUrl ("PCtsave"') .build()" 
method="post" commandName="product'"> 
<div> 
<label for="title''>Titulo</label> 
<form: input path="title'"/> 
<form:errors path="title'/> 
</div> 
<div> 
<label for="description">Descrição</label> 
<form: textarea path="description" rows="10" 
cols="20"/> 
</div> 
<div> 
<label for='releaseDate">Data de lançamento</label> 
<form: input path='releaseDate'" type="date'/> 
<form:errors path='releaseDate"/> 
</div> 
</form: form> 


Fizemos uso daquele conjunto de tags específicas para o formulário. Além 
da errors, usamos a input ea textarea. Perceba que todas têm o 
atributo path, que define a propriedade do modelo que queremos usar. 
Vale lembrar que não estamos nos referindo ao atributo privado e sim aos 


getters expostos na classe. Basicamente, o que essas tags fazem é acessar 
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a variável com o mesmo nome do commandName, e ir invocando os getters 


necessários. 


O método form e o atributo commandName 


Caso o leitor mais curioso tenha executado o código com as tags de ajuda 
do formulário, neste momento, ele terá recebido uma exception um tanto 


quanto estranha. 


java. lang. IllegalStateException: Neither BindingResult nor 
plain target object for bean name product? available as 
request attribute 


Quando acessamos a tela do formulário pela primeira vez, através da 
URL /produtos/form, fazemos uso do método form(), da classe 
ProductsController. Já foi explicado que, para a tag form: form fun- 
cionar, ela precisa de acesso ao objeto recebido como parâmetro. No caso 
desse nosso método, onde está o parâmetro? É justamente por esse motivo 
que estamos recebendo essa exception. 


Para conseguirmos contornar isso, vamos fazer uma leve alteração. 


public ModelAndView form(Product product) { 


Forçamos o método form a receber um parâmetro do tipo Product, 
apenas para o Spring MVC disponibilizá-lo como variável do request. Caso 
você esteja pensando que essa alteração está sendo imposta pelo framework, 
vá se acostumando. Muitas vezes temos que escrever um código que não que- 
remos apenas para agradar a tecnologia em questão, mas dado que já ganha- 
mos bastante, é um tradeoff mais do que justo. Agora, para nosso código 
voltar a compilar, é necessário alterar a invocação do método form a partir 


do método save. 


public ModelAndView cadastra(0Valid Product product...) 
if (bindingResult .hasErrors()){ 
return form(product) ; 
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A ANNOTATION QMODELATTRIBUTE 


Estamos sempre configurando o atributo commandName com o 
mesmo nome do tipo do parâmetro recebido no método. Caso você 
queira alterar isso, por exemplo passando o valor “objeto Atual”, pode uti- 
lizar a annotation EModelAttribute. 


save(@Valid @ModelAttribute("objetoAtual") Product product) 


Essa annotation pode ser útil caso, por algum motivo, sua empresa 
tenha uma padrão para nomes de variáveis disponíveis na sua JSP. 











5.5 INTEGRAÇÃO COM A BEAN VALIDATION 


A nossa validação já funciona integralmente, mas ainda tem um ponto que, 
pelo menos para este autor, ainda é um pouco ruim. O nosso validador cus- 
tomizado realiza verificações muito básicas. 


ValidationUtils.rejectIfEmptyOrWhitespace(errors, 
"title", "field.required"); 


Esse tipo de validação é tão comum que, como já comentamos, virou até 
especificação no mundo Java, a Bean Validation. E como não podia ser di- 
ferente, o módulo de validação é completamente integrado com ela. Só para 
lembrar o leitor, já configuramos o Maven para utilizarmos a implementação 
feita pelo time do Hibernate, chamada de Hibernate Validator. O primeiro 
passo, para a felicidade de qualquer equipe de programação, é que não pre- 
cisamos do nosso validador customizado. Logo, lembre de apagá-lo do seu 
código, ou pelo menos não configure mais para ele ser utilizado pelo Spring 
MVC. 


//por enquanto não precisamos mais desse metodo. 

//Comente ou apague. 

OInitBinder 

protected void initBinder (WebDataBinder binder) { 
binder.setValidator (new ProdutoValidator ()); 
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Agora precisamos de outra forma para ensinar o Spring MVC que ele pre- 
cisa validar os dados básicos de um livro. 


CEntity 
public class Product { 


@Id 

@GeneratedValue (strategy = GenerationType. IDENTITY) 
private Integer id; 

CNotBlank 

private String title; 

OLob 

CNotBlank 

private String description; 

@Min (30) 

private int pages; 


Pronto, com algumas annotations conseguimos o mesmo efeito de vali- 
dação. Agora, caso você teste um novo cadastro inválido, as mensagens de 
validação ainda não estarão da maneira como esperamos. 


e ONotBlank -> “may not be empty” 


* @Min -> “must be greater than or equal to ?” 


Como já fizemos antes, vamos alterar o arquivo message .properties 





e adicionar as novas chaves de validação. 


NotBlank.java.lang.String = Campo obrigatorio 
NotBlank.product.title = Titulo obrigatório 
Min.product.pages = 0 numero minimo de paginas é {1} 


Perceba que simplesmente adicionamos o nome da annotation na frente 
da chave, o resto segue o mesmo padrão que já utilizamos. Um ponto a ser 
observado é a mensagem referente ao mínimo de páginas. Temos que usar o 
valor do argumento que foi configurado na annotation. 


@Min (30) 
private int pages; 
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O Spring MVC disponibiliza isso como parâmetro da sua mensagem. No 
caso da mensagem de validação, o argumento (0) sempre é o nome do atri- 
buto sendo validado. Por isso, foi usado o (1). Caso você queira alterar as 
mensagens padrões, que estão associadas a cada uma das annotations da Bean 
Validation, siga este link: http://tinyurl.com/oocl5ro. 


org.hibernate.validator.constraints.NotBlank.message = 
may not be empty 


Ele vai lhe fornecer as chaves necessárias, que devem ser substituídas, para 
que o Hibernate Validator trabalhe com as mensagens customizadas. Basta 
que você copie no seu arquivo messages e troque o valor associado a ela. 


org.hibernate.validator.constraints.NotBlank.message = 
Campo obrigatório 


5.6 CONVERTENDO A DATA 


Na Casa do Código, muitos livros são escritos o tempo todo. Para ter um fluxo 
interessante de lançamentos, foi decidido que os livros cadastrados devem ter 
uma data de lançamento. 


CEntity 
public class Product 1 


private Calendar releaseDate; 


//getter e setter. 


} 
Agora precisamos colocar um campo novo no nosso formulário. 
<div> 
<label for="releaseDate">Data de lançamento</label> 
<input type="date" name="releaseDate"/> 
<form:errors path="releaseDate"/> 
</div> 
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Caso nosso usuário efetue o teste, aparecerá uma mensagem de falha de 
conversão. 


Failed to convert property value of type java.lang.String to 
required type java.util.Calendar for property releaseDate; 
nested exception is java.lang.IllegalStateException: Cannot 
convert value of type [java.lang.String] to required type 
[java.util.Calendar] for property releaseDate: no matching 
editors or conversion strategy found 


A exception indica que o Spring MVC não conseguiu achar, de maneira 
automática, um conversor de String para o tipo Calendar. Para que este 
problema seja resolvido, é necessário usarmos uma annotation indicando que 
queremos a conversão. 


ODateTimeFormat 
private Calendar releaseDate; 


Agora, se tentarmos mais uma vez o cadastro, receberemos a seguinte 
exception de conversão: 


Failed to convert property value of type java.lang.String to 
required type java.util.Calendar for property releaseDate; 
nested exception is 

org. springframework.core.convert.ConversionFailedException: 
Failed to convert from type java.lang.String to type 
Corg.springframework. format. annotation.DateTimeFormat 
java.util.Calendar for value 2015-02-20; nested exception is 
java. lang. IllegalArgumentException: Unable to parse 2015-02-20 


O problema é que o formato default usado pelo conversor re- 
gistrado no Spring MVC é o M/d/yy, representado pela constante 
DateFormat . SHORT; e o valor enviado pelo nosso formulário, já que usa- 
mos o input cujo tipo éo date, sempre vai no formato yyyy-MM-dad. Para a 
nossa sorte, esse formato é o muito usado no mundo http://pt.wikipedia.org/ 
wiki/ISO 8601 e o Spring MVC já tem o suporte pronto. 


ODateTimeFormat (iso=ISO.DATE) 
private Calendar releaseDate; 
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Redefinindo o formato global 


Sempre que temos de lembrar de fazer alguma configuração no nosso có- 
digo, por vários motivos, acabamos esquecendo e passando muito tempo ten- 
tando corrigir. É justamente o que pode acontecer com a nossa estratégia de 
conversão atual. Sempre temos que nos lembrar de pôr o estilo de conversão 
na annotation GDateTimeFormat 

Para melhorar essa parte da nossa aplicação, vamos ensinar ao Spring 
MVC que ele sempre deve usar essa formatação. Vamos adicionar mais um 
método na classe AppWebConfiguration 


CBean 
public FormattingConversionService mvcConversionService() 1 
DefaultFormattingConversionService conversionService = 
new DefaultFormattingConversionService(true); 


DateFormatterRegistrar registrar = 
new DateFormatterRegistrar (); 
registrar. setFormatter (new DateFormatter ("'yyyy-MM-dd")); 
registrar.registerFormatters (conversionService); 
return conversionService; 


Respire, pois está acontecendo muita coisa nesse código. A primeira in- 
formação é que o nome do método tem que ser mvcConversionService. 
Pois esse é o nome usado internamente pelo Spring MVC para registrar o ob- 
jeto responsável por agrupar os conversores. Para que isso não pareça tão 
mágico, o leitor pode checar a classe WwebMvcConfigurationSupport, di- 
retamente no código-fonte do Spring, http://tinyurl.com/na3g9jp. 

O próximo passo importante é o uso do objeto do tipo 
DateFormatterRegistrar. Ele implementa a interface 
FormatterRegistrar, que deve ser usada quando é necessário agrupar 
vários tipos de conversões. No caso da data, temos várias possibilidades, 
seguem alguns exemplos. 


e Calendar para Long 


* Long para Calendar 
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* Date para Calendar 
e Calendar para Date 


Depois de criarmos o objeto do tipo DateFormatterRegistrar, in- 
formamos qual a formatação que deve ser aplicada por padrão. 


registrar. setFormatter (new DateFormatter ("yyyy-MM-dd')); 


Por fim, é feito o registro de todos os conversores no objeto do tipo 
FormattingConversionService. O mesmo é instanciado com um true 
no construtor, indicando que todos conversores padrões, devem ser adicio- 
nados. 


Entendendo mais sobre os formatadores do Spring MVC 


Uma das belezas dos formatadores do Spring MVC é que a nossa confi- 
guração de formatação das datas vale para os dois lados da moeda. 


* A String de entrada é convertida para o Calendar do seu modelo. 


e O Calendar do seu modelo é formatado para ser apresentado no for- 
mulário. 


Para ficar mais claro, dê uma olhada na interface que define os formata- 
dores. 


public interface Formatter<T> extends Printer<T>, Parser<T> { 


} 


As tags do Spring MVC tiram proveito dos formatadores, com isso não 
precisamos ficar nos preocupando em tratar os dados que devem ser exibidos 
nos inputs dos formulários. 


<div> 
<label for="releaseDate">Data de lançamento</label> 
<form: input path="releaseDate" type="date"/> 
<form:errors path="releaseDate"/> 

</div> 


Perceba que só indicamos o nome da propriedade que deve ser usada e, 
pelo tipo da mesma, o Spring MVC vai decidir qual formatador utilizar. 
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5.7 CONCLUSÃO 


Conseguimos cobrir tudo que é necessário para você aplicar as validações 
necessárias nos sistemas que serão desenvolvidos. Passamos pela fase onde 
você mesmo poderia criar o seu validador e vimos como lidar com o erro de 
validação redirecionando o usuário para o local correto. Também analisamos 
as possibilidades de configuração das mensagens de erros e como exibir as 
mesmas dentro das páginas. 

Para fechar, fomos além e vimos a integração com as annotations da Bean- 
Validaton e entendemos como funcionam os conversores de tipos dentro do 
Spring MVC. Minha dica, nesse momento, é que você descanse um pouco, 
tente praticar o que vimos até aqui e só depois continue a leitura. 
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Upload de arquivos 


Uma característica importante das livrarias online é a disponibilização do su- 
mário dos livros que estão à venda. A Casa do Código, como não poderia 
deixar de ser, também deve oferecer essa possibilidade a seus usuários. 


6.1 RECEBENDO O ARQUIVO NO CONTROLLER 


Vamos começar alterando a página da Casa do Código responsável pela en- 
trada de dados de cada um dos novos livros. 


<form:form action="$(spring:mvcUrl (*PCtsave?) .build() + 
method="post" 
commandName="product"> 
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<div> 
<label for="summary">Sumario do livro</label> 
<input type="file'! name="summary'"/> 
<form:errors path="summaryPath'"/> 

</div> 


A única mudança foi a adição do input que vai receber o arquivo que, 
neste caso, deve ser do tipo file. Agora, se tentarmos enviar os dados desse 
formulário, devemos receber o seguinte resultado: 





PTE Exception report 


TT teoes sescessos fale. DERON epentian a AR ser pero rr MTE TIE ATEK MRAR i TA, IG 
TESS De sarar enconetarné po internal serne that preantas R from Sil tres aaee. 










»egunpringtramenorh wub util MestodsorvietEnception: Request processing failed; se 
org. apringframevork vob. serv! amevorkServlot .procnsai 


eq. mpringtrameora.vob.multipart.MsltipartExcoptions The curront cequost is sot s muitipart request 
or od. annotat ion. RequestParasketbodArgunentãeso! tisMaltipartRequest (Request Par anothodArgansatRosolver. java12:8) 
od annotat ion. Request ParasMothodArquaent Reso: volazo (Request ParamMothodArgumentRosolver . java 1185) 
ration.AbstractNamodVa LueMot hodhr gama: MothodÃrqumsntResolver. Sava 189) 
and Ler Hot hodAr quecntBescivertcapo. 35) 
ndierMethod + SodAr ques: 











aolvertomposite. java: 







t -dobispatch(Dispa 


Fig. 6.1: O request não é multipart 


“The current request is not a multipart request 

signifca que tentamos enviar o arquivo de uma maneira que o Spring 
MVC não consegue entender. Basicamente, o que acontece é que todos 
os dados do formulário são enviados de alguma forma e, o default é que 
eles sejam submetidos usando o formato application/x-www-form- 
urlencoded. Desse modo, os dados são enviados seguindo quase que as 
mesmas regras utilizadas quando utilizamos o método GET. Uma sequência 
de chaves e valores. 

A nossa situação atual exige que façamos uma alteração nesse formato, 
de modo que o arquivo possa ser integralmente passado do navegador para o 
servidor. É por isso que vamos utilizar o formato multipart /form-data. 
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<form:form action="$(spring:mvcUrl (*PCtsave?) .build() + 
method="post" 
commandName="product" 
enctype="multipart/form-data"> 


</form> 

O atributo enctype serve justamente para indicarmos como queremos 
mandar os dados do navegador para o servidore o multipart/form-data 
é o jeito utilizado quando necessitamos transmitir arquivos. Por exemplo, já 
existe um trabalho sendo feito para que o seu form possa enviar os dados 


através do formato JSON. Caso fique curioso, navegue até http://www.w3. 
org/TR/html-json-forms/. 


Alterando o método do controller 


Agora que nosso formulário já envia o arquivo, precisamos 
recebê-lo e lidar com ele. Faremos isso no método save da classe 


ProductsController 


public class ProductsController { 
ORequestMapping (method=RequestMethod.POST) 
public ModelAndView save( 
Part summary, 0OValid Product product,...) 1 
System.out.printlin (summary .getName() + ";" 
+summary. getHeader("content-disposition")); 
//resto do código 


A parte importante desse código é o parâmetro do tipo Part. Ele foi 
introduzido a partir da versão 3 da especificação de Servlets e a interface res- 
ponsável por representar o arquivo que foi enviado pelo formulário. Perceba 
que o nome do argumento é o mesmo nome do input que declaramos no for- 


mulário. Aqui usamos dois métodos: 


e get Name (): retorna o nome do input usado no formulário; 
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* getHeader (): usado para recuperar alguma informação sobre o que 
foi enviado. 


E caso a gente queira recuperar o nome do arquivo, como vamos fazer? 
O leitor mais experiente deve estar pensando que tem algum método que já 
retorna isso pronto e esse é justamente o problema. A interface Part é a 
maneira mais primitiva de tratarmos os dados enviados através do enctype 
multipart/form- data. Na verdade, podemos acessar o valor de cada 
um dos campos do formulário, basta que declaremos um parâmetro do tipo 
Part para cada input. Para ficar um pouco mais claro, dê uma olhada na 
maneira como esses dados são enviados a partir do navegador. 


v Request Payload 
——— WebkKitFormBoundaryjxJhEFLIONIbmBuz 
Content-Disposition: form-data; name="title" 


—————WebKitFormBoundary jxJhEF LION3bmBuz 
Content-Disposition: form-data; name="description" 


—————WebKitFormBoundary jxJhEF LION3bmBuz 
Content-Disposition: form-data; name="pages" 


=———— WebKitFormBoundaryjxJhEF LION3bmBuz 
Content-Disposition: form-data; name="releaseDate" 


—-———WebKitFormBoundaryjxJhEF LION3bmBuz 
Content-Disposition: form-data; name="summary"; filename="21-Usando Métodos Ágeis para ensinar Métodos Ágeis. pdf 
Content-Type: application/pdf 


--——] WebKitFormBoundaryjxJhEFLION3bm8uz 
Content-Disposition: form-data; name="prices [0].value" 





Fig. 6.2: Corpo do request para uma requisição multipart 


Para os campos que não representam arquivos, o Spring MVC já nos ajuda 
bastante e faz a ligação direta com as propriedades do nosso modelo. Para 
não nos decepcionar, ele também oferece um jeito mais fácil de lidar com o 
arquivo que foi submetido. 


public class ProductsController { 
ORequestMapping (method=RequestMethod.POST) 
public ModelAndView save (MultipartFile summary, 
OValid Product product,...) 1 
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System. out .println (summary .getName() + ";" 
+summary.getOriginalFilename()); 
//resto do código 


O método getName continua fazendo a mesma coisa, só que agora já 
temos outro método, o getOriginalFilename (), que já nos retorna o 


nome do arquivo que foi enviado. 


6.2 SALVANDO O CAMINHO DO ARQUIVO 


Agora que já temos o objeto que representa o arquivo enviado em nossas 


mãos, é necessário gravá-lo em algum lugar. 


public class ProductsController { 


OAutowired 
private FileSaver fileSaver; 


ORequestMapping (method=RequestMethod.POST) 
public ModelAndView save (MultipartFile summary, 
@Valid Product product,...) 1 
//faz a validação 


String webPath = 

fileSaver.write("uploaded-images", summary); 
product. setSummaryPath(webPath); 
products.save(product); 


//fim do método 


} 


@Component 
public class FileSaver { 


@Autowired 
private HttpServletRequest request; 
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public String write(String baseFolder, MultipartFile file) 1 

String realPath = request .getServletContext () 
.getRealPath(''/"+baseFolder) ; 

try A 
String path = 

realPath+'/"+file.getOriginalFilename(); 

file.transferTo(new File(path)); 
return baseFolder+'"/"+file.getOriginalFilename(); 

} catch (IOException e) 1 
throw new RuntimeException(e); 


Dê uma respirada e olhe com cuidado para o código. Perceba que não 
fizemos nada demais, apenas criamos outra classe responsável por gravar o 
arquivo em uma pasta da nossa aplicação. A ideia é não deixar que esse có- 
digo atrapalhe o fluxo do método save, no nosso controller. Além disso 
é necessário criar o atributo summaryPath na classe Product, juntamente 
com o seu getter e setter. 

Dessa forma, caso seja necessário criar um link para o sumário, basta que 
façamos algo parecido com o que segue: 


<img src="$fproduct. summaryPath)J'/> 


6.3 CONFIGURAÇÕES NECESSÁRIAS 


Caso você tenha rodado a aplicação, percebeu que nosso upload de arqui- 
vos ainda não está funcionando. Está sendo lançada uma exception do tipo 





IllegalArgumentException 


java. lang. IllegalArgumentException: Expected 
MultipartHttpServletRequest: is a MultipartResolver configured? 


A interface MultipartResolver é a que define os métodos necessá- 
rios para o tratamento inicial de um request cujo modo de envio, também 
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conhecido como content Type,éo multipart/form-data. Precisamos 
prover uma implementação dessa interface para que o Spring MVC possa fa- 
zer seu trabalho. Para isso, basta que adicionemos mais um método na classe 
AppWebConfiguration. 


CEnableWebMvc 

CComponentScan (basePackageClasses=(HomeController.class, 
ProductDAO. class,FileSaver.class+) 

public class ApphWebConfiguration { 


CBean 
public MultipartResolver multipartResolver 01 
return new StandardServletMultipartResolver(); 


Aqui foi escolhida a implementação que usa o recurso de tratamento de 
upload provido pela especificação de Servlets. Outra alternativa é usar a im- 
plementação baseada na biblioteca commons-fileupload. Nesse caso, a 
classe escolhida seriaa CommonsMultipartResolver. 

Além disso, na annotation @ComponentScan, passamos a classe 
FileSaver com o objetivo de que o Spring vasculhe o pacote em que ela 
se encontra. 

Agora, caso o leitor tente salvar um novo livro, vai receber mais uma ex- 
ception. Só que desta vez ela é diferente, o que indica que resolvemos o pro- 
blema anterior. 


java. lang. IllegalStateException: Unable to process parts as 
no multi-part configuration has been provided 


A parte mais importante dessa exception é: “no multi-part configuration 
has been provided 

. Quando configuramos o tratamento de upload, podemos definir algu- 
mas coisas: 


e Local de armazenamento temporário enquanto o arquivo está sendo 
recebido; 
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e Tamanho máximo do arquivo; 
e Tamanho máximo do request como um todo. 


Na especificação de Servlets, essa configuração é feita através da classe 





MultipartConfigElement. 


//outros imports 
import javax.servlet.ServletRegistration.Dynamic; 


public class ServletSpringMVC extends 
AbstractAnnotationConfigDispatcherServletInitializer { 


QUverride 
protected void customizeRegistration(Dynamic registration) 1 
registration.setMultipartConfig( 
new MultipartConfigElement ('"'')); 


Só para lembrar, a classe ServletSpringMvC fornece itens básicos 
como: mapeamento de URL do servlet do Spring MVC e quais outras classes 
de configurações devem ser carregadas. Agora, além disso, sobrescrevemos o 
método customizeRegistration. Ele recebe como parâmetro um objeto 





do tipo Dynamic, que nos possibilita, entre outras coisas, registrar o nosso 





objeto de configuração do tipo MultipartConfigElement. O constru- 
tor recebendo apenas uma String vazia indica que o próprio servidor web vai 
decidir qual é o local de armazenamento temporário dos arquivos. 

Pronto, agora nossa aplicação está pronta para receber qualquer tipo de 


arquivo através dos formulários. 


6.4 GRAVANDO OS ARQUIVOS FORA DO SERVIDOR 
WEB 


Nossa lógica de upload grava os novos arquivos em uma pasta dentro da pró- 
pria aplicação web. O problema dessa abordagem, mesmo quando estamos 
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em ambiente de desenvolvimento, é que a cada nova alteração que temos no 
projeto a nossa IDE força um hot deploy no servidor. Em geral, o hot deploy 
destrói a aplicação que estava no servidor e cria uma nova, fazendo com que 
percamos os arquivos que já tinham sido enviados. 

Além disso, um fato que incomoda o desenvolvedor é perceber que os 
arquivos enviados não ficam exatamente dentro do projeto que ele está visu- 
alizando, por exemplo, no Eclipse e sim na instalação do servidor que foi es- 
colhida. Para simplificar tudo isso, facilitando inclusive o processo de deploy 
que discutiremos mais para o fim do livro, é que podemos usar um serviço 
como o Amazon $3. Basicamente, a Amazon fornece um servidor onde po- 
demos enviar nossos arquivos e eles ficam disponíveis para serem acessados 
pela web. Eles possuem servidores dedicados só para isso. 


Integração com o Amazon S3 


Para quem estiver interessado nessa opção, a primeira coisa que devemos 
fazer é alterar o código que está na classe FileSaver, que é a responsável 


por gravar o arquivo. 


CComponent 
public class FileSaver { 


public String write(String baseFolder, 
MultipartFile multipartFile) { 
AmazonS3Client s3 = client(); 
try A 
s3.putObject (''casadocodigo", 
multipartFile.getOriginalFilename(), 
multipartFile.getInputStream(), 
new ObjectMetadata()); 


return "https://s3.amazonaws.com/casadocodigo/! 
+multipartFile.getOriginalFilename(); 


} catch (AmazonClientException | I0Exception e) { 
throw new RuntimeException(e); 
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private AmazonS3Client client() 1 
AwSCredentials credentials = new BasicAWSCredentials( 


); 
AmazonS3Client newllient = 
new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions(new S3ClientOptions () 
.withPathStyleAccess(true)); 
return newClient; 


Perceba que temos mais códigos relativos à integração com a Amazon do 
que relacionado ao Spring em si. De tudo que foi escrito anteriormente, as 
linhas mais importantes são as que estão a seguir: 


AmazonS3Client s3 = client (); 


s3.putlbject(''casadocodigo!", 
multipartFile.getOriginalFilename(), 
multipartFile.getInputStream(), 
new ObjectMetadata()); 


O objeto do tipo AmazonS3Client encapsula toda a lógica e o proto- 
colo de comunicação com a Amazon. O nosso único trabalho é passar os 


parâmetros. 


e O primeiro é a pasta remota onde o arquivo vai ser salvo, também co- 
nhecido como bucket; 


e O segundo é o nome do arquivo; 
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e O terceiro é alguma implementação da classe InputStream, que re- 
almente representa o arquivo; 


e O quarto são informações extras como: data de expiração do arquivo e 
qualquer outra informação que seja específica da aplicação. 


A outra parte do código é a mesma para qualquer integração que você vá 
fazer com a Amazon. Sempre precisamos criar um objeto que contém as cre- 
denciais de acesso, para garantir que só o dono da conta possa fazer uploads 
para o bucket. 


private AmazonS3Client client() 1 
AwSCredentials credentials = new BasicAWSCredentials( 


); 
AmazonS3Client newClient = new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions (new S3ClientOptions () 
.withPathStyleAccess(true)); 
return newClient; 


Basicamente essas seriam as alterações que teríamos que fazer no nosso 
código. Como deixamos encapsulada a lógica de gravação do arquivo, não 
somos obrigados a alterar nenhuma linha do nosso controller. 


Simulando o S3 localmente 


O empecilho com essa solução é que vamos ter que realmente criar um 
conta na Amazon para conseguir realizar nossos testes, o que é completa- 
mente inviável. Para resolver este problema, existe um projeto chamado S3 
Ninja, que pode ser encontrado em http://s3ninja.net/. Eles criam este pro- 
jeto com o objetivo de servir como um emulador para o S3 real, da Amazon. O 
S3 Ninja é uma aplicação web escrita em Java que sobe um servidor que aceita 
requisições vindas do próprio SDK da Amazon. Justamente o que estávamos 
procurando. Uma parte muito boa é que seu uso é bem simples. 

O primeiro passo é realizar o download do zip. Basta acessar o ende- 
reço https://oss.sonatype.org/content/groups/public/com/scireum/s3ninja/2. 
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3/s3ninja-2.3-zip.zip. Você também pode encontrar o link no readme do 
GitHub do projeto em https://github.com/livrospringmvc/lojacasadocodigo. 
Uma vez que você baixou o projeto, descompacte em uma pasta da sua prefe- 
rência. Ainda dentro da pasta descompactada, precisamos criar um estrutura 
simples de subpastas que vão simular os buckets da Amazon. Vamos criar 
primeiro a pasta data e, dentro dela, criaremos uma outra, chamada s3. A 
estrutura final vai ficar parecida com a que segue. 


META-INF 
L— maven 


app 


assets 
ninja 
view 

data 

L- s3 

lib 

logs 


Fig. 6.3: Estrutura de pastas do s3 ninja 


Agora que a estrutura está criada, basta que iniciemos o servidor do S3 
Ninja. 


java IPL 


Perceba que IPL é justamente um arquivo java compilado que já vem 
na raiz do diretório descompactado. Após executar o comando, você deve ver 
a seguinte saída. 


INITIAL PROGRAM LOAD 


IPL from: /Users/alberto/ambiente/servidores/s3ninja-2.3-zip 
IPL completed - Loading Sirius as stage2... 


Opening port 9191 as shutdown listener 


O servidor está rodando no endereço http://localhost:9444/. Você pode 
acessá-lo pelo navegador. 
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, 83 ninja 





e, License Implemented API 


Actesa Logs 


Fig. 6.4: Tela de boas-vindas do s3 ninja 


Agora que o nosso emulador está rodando, precisamos alterar o código 
de configuração de acesso a Amazon e fazê-lo apontar para o servidor local. 


private AmazonS3Client client() { 
AWSCredentials credentials = new BasicAWSCredentials( 
); 
AmazonS3Client newClient = new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions (new S3ClientOptions () 
.withPathStyleAccess(true)); 


//nova linha 
newClient.setEndpoint ("http://localhost :9444/s3"); 
return newClient; 


Pronto! Quando cadastrarmos um novo livro, o arquivo do sumário vai 
ser gravado na pasta data /s3/casadocodigo/nomedoarquivo,nolocal 
que você escolheu para executar o S3 Ninja. Perceba que também alteramos 
o retorno do método write, da classe FileSaver. 


public String write(String baseFolder, 
MultipartFile multipartFile) { 
AmazonS3Client s3 = client(); 
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try É 
s3.putlbject(''casadocodigo", 
multipartFile.getOriginalFilename(), 
multipartFile.getInputStream(), 
new ObjectMetadata()); 


//url de acesso ao arquivo 
return "https://s3.amazonaws.com/casadocodigo/" 
+multipartFile.getOriginalFilename()+"'?noAuth=true"; 


+ catch (AmazonClientException | I0Exception e) { 
throw new RuntimeException(e); 


A ideia é que é nosso método já retorne o endereço de acesso ao arquivo 
enviado, para que possamos usá-lo nos links do nosso sistema. 


Isolando a criação do AmazonS3Client 


A nossa alteração nos levou a deixar o código de criação do objeto de 
acesso à Amazon misturado com o código da classe FileSaver. Como já 
discutimos quando recebemos injetado o DAO, o nosso objetivo nesse código 
é usar o cliente da Amazon e não ficar criando. Portanto, vamos começar 
recebendo um objeto do tipo AmazonS3Client, em vez de criá-lo. 


CComponent 
public class FileSaver { 


OAutowired 
private AmazonS3Client s3; 


public String write(String baseFolder, 
MultipartFile multipartFile) 1 
try É 
s3.putObject ("'casadocodigo", 
multipartFile.getOriginalFilename(), 
multipartFile.getInputStream(), 
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new ObjectMetadata()); 


return "http://localhost :9444/s3/casadocodigo/" 
+multipartFile 
.getOriginalFilename ()+"?noAuth=true"; 


+ catch (AmazonClientException | I0Exception e) { 
throw new RuntimeException(e); 


Para este código funcionar, precisamos criar uma classe de configuração 
que construa o objeto para nós. 


package br.com.casadocodigo.loja.conf; 
import org.springframework.context.annotation.Bean; 


import com.amazonaws.ClientConfiguration; 

import com.amazonaws.auth. AWSCredentials; 

import com.amazonaws.auth.BasicAWSCredentials; 
import com.amazonaws.services.s3.AmazonS3Client; 
import com.amazonaws.services.s3.53ClientOptions; 


public class AmazonConfiguration { 


CBean 
public AmazonS3Client s3Ninja() 1 
AWSCredentials credentials = new BasicAWSCredentials( 
); 
AmazonSSClient newClient = 
new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions (new S3ClientOptions () 
.withPathStyleAccess(true)); 
newClient.setEndpoint ("http://localhost :9444/s3"); 
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return newClient; 


Perceba que é uma classe normal, apenas criamos um método e usamos 
anotação @Bean para dizer que ele produz um objeto que deve ser gerenciado 
pelo Spring. O último passo é ensinar ao Spring que essa classe existe e, para 
isso, vamos alterar a classe Servlet SpringMVC. 


package br.com.casadocodigo.loja.conf; 


public class ServletSpringMVC extends 
AbstractAnnotationConfigDispatcherServletInitializer { 


QUverride 
protected Class<?>[] getRootConfigClasses() { 
return new Class[] { SecurityConfiguration.class, 
AppWebConfiguration.class, 
JPAConfiguration.class, 
AmazonConfiguration.class +; 


Agora você tem duas opções para salvar os arquivos enviados pelos seus 
usuários. Este autor sugere que você sempre guarde o arquivo em um local 
fora do servidor web. A complexidade adicionada ao projeto é compensada 
pela flexibilidade de manter os arquivos entre reloads da aplicação, em tempo 
de desenvolvimento. Além disso, a instalação no ambiente de produção vai ser 
facilitada, já que você não vai ter que se preocupar em manter os arquivos que 
já tenham sido enviados pelos usuários. Tudo vai estar em um lugar separado. 
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6.5 CONCLUSÃO 


Neste capítulo, focamos unicamente no upload de arquivos. Essa é uma fun- 
cionalidade muito comum nas aplicações, mas muitas vezes esquecemos de 
olhar com detalhes, para entender exatamente como funciona. Espero que 
este capítulo tenha ajudado a deixar as configurações um pouco mais claras 
para você. 

Não pare agora, já vá para o próximo capítulo onde vamos simular o fe- 
chamento de uma compra e a integração com um outro sistema. Também 
vamos ver como podemos ajudar o servidor a processar requests mais lon- 
gos. 
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Carrinho de compras 


Já temos o cadastro de livros e a listagem dos mesmos na loja da Casa do Có- 
digo, chegou o momento de implementarmos o processo de compra. Para co- 
meçarmos essa fase, precisamos, primeiramente, possibilitar que os usuários 
escolham os livros que mais lhes interessam e os coloquem em um carrinho 
de compras. 


7.1 URI TEMPLATES 


Vamos tentar seguir exatamente o mesmo processo usado no site da Casa 
do Código. Por lá, para o visitante do site colocar um livro no carrinho, ele 
precisa navegar até a página de detalhes do livro. 


71. URI templates Casa do Código 





Explorando APIs e bibliotecas 
Java: JDBC, IO, Threads, JavaFX 
e mais 


Rodrigo Turini 


Uma vez que você aprende orientação a objetos e o básico do Java, é necessário se tornar 
fluente em suas APIs, que não são poucas. Um programador java eficaz conhece o que há 
disponivel e sabe quando pode usar cada uma das possibilidades que a linguagem lhe 
oferece. É isso que queremos para você. 


Rodrigo Turini te ensina como lidar com as diferentes APIs do java, com exemplos práticos e 
que são relevantes no seu dia a dia. Você val aprender as diferentes APIs para fazer 10, 
trabalhar com Threads da forma correta, se conectar com banco de dados via JDBC, integrar com ferramentas de bulld e muito 
mais. 








Fig. 7.1: Página de detalhes do livro 


Para seguir a mesma ideia, vamos criar a nossa página de detalhes 
do livro. Aqui, para ficar ainda mais claro que estamos literalmente re- 
produzindo a aplicação, será usado o mesmo HTML da Casa do Código. 


r4 


Como o código da página é relativamente grande, o leitor pode nave- 
gar até o link https://github.com/livrospringmvc/lojacasadocodigo/blob/ 
master/src/main/webapp/WEB-INF/views/products/show.jsp 

para ver a página completa. No trecho a seguir, veja 


algumas partes importantes. 


<header id="product-highlight" class="clearfix"> 
<div id="product-overview"! class="container"> 

<img itemprop="image" width="280px" height="395px" 
src="? 
class="product -featured-image" 
alt="$(product .titleJ"!> 

<h1i class="product-title'! itemprop="name"> 
$fproduct .title) 

</h1> 

<p class="product-author"> 
<span class="product-author-link"> 

${product.title} 
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</span> 
</p> 


<p itemprop="description" class="book-description'> 
$fproduct. description) 
Veja o <a 
href="<c:url value=? /$(product . summaryPath)Jº/>" 
target=" blank''>sumk4225;rio</a> completo do 
livro! 
</p> 
</div> 
</header> 


<section class="buy-options clearfix"> 
<form action="<c:url value="/shopping'/>" method="post" 
class="container"> 
<input type="hidden" value="$fproduct .id)J" 
name="productId''/> 
<ul id="variants" class="clearfix'> 
<c:forEach items="$(product.pricesy! var="price"> 
<li class="buy-option"> 


<input type="radio" 

name="bookType" class='"variant-radio" 
id="$fproduct .id]-$fprice.bookType" 

value="$(price.bookType" 

$fprice.bookType.name () ==’ COMBO’ ?’ checked’ :?? 

+ 


<label class='variant-label" 
for="$(product .id)-$fprice.bookTypeJ''> 
$fprice.bookTypeJ 

</label> 

<p class='variant-price'>$fprice.valuej</p> 

</li> 
</c:forEach> 
</ul> 


<input type="submit" class="submit-image icon-basket-alt" 
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alt="Compre agora" 
title="Compre agora ’${product.title}?!" 
value="comprar'"/> 
</form> 
</section> 


Apenas para você não ficar perdido, o nome desse arquivo é show. jsp 





e fica na pasta WEB-INF /views/products. 

Perceba que simplesmente usamos as informações que já possuíamos so- 
bre um determinado produto. O único ponto para o qual ainda não fizemos 
o suporte é paraa URL /shopping, cujo controller vai ser responsável por 
adicionar o produto no carrinho de compras. Ainda não se preocupe com 
ela, vamos resolver isso no momento correto. Um outro detalhe com que não 
nos preocupamos foi o de recuperar os arquivos de estilos usados pela Casa 
do Código, estamos apenas reaproveitando a estrutura do HTML. 

Agora que já temos a página, é necessário construir o método do control- 
ler que carrega o produto. Faremos isso na classe Product sController. 


ORequestMapping (method=RequestMethod.GET, value="/show!') 
public ModelAndView show(Integer id) 
ModelAndView modelAndView = 
new ModelAndView("products/show'!); 
Product product = productDAO.find(id); 
modelAndView.addObject ("product'!, product); 
return model AndView; 


Precisamos também adicionar um link na listagem de produtos, para que 
os usuários possam fazer a navegação pela nossa aplicação. 


<c:forEach items="$(products)" var="product"> 
<tr> 
<td> 
<a 
href="$(spring:mvcUrl(ºPCishow”) .arg(0,product. id) 
«build (O) H'> 
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$fproduct.title) 
</a> 
</td> 
<td> 
<c:forEach items="$(product.pricesy! var="price"> 
[$fprice.valuej - $fprice.bookTypeJ] 
</c:forEach> 
</td> 
</tr> 
</c:forEach> 


Mais uma vez fizemos uso da função mvcUr1, para que ela nos ajude a 
montar a URL. A única diferença é que, antes de invocar o método build (), 
tivemos que chamar o arg (indice, valor) para que o endereço possa ser 
montado utilizando corretamente os parâmetros. 

O endereço que aparece, após o usuário clicar no link que leva para a pá- 
gina de detalhe do produto, é o casadocodigo/produtos/show?id=2. 
Na verdade, essa é a maneira padrão de passar parâmetros via get só que, se 
olharmos para o mesmo endereço no site da Casa do Código, veremos que ele 
possui uma estrutura um pouco diferente, http://www.casadocodigo.com.br/ 
products/livro-apis-java. 

O trecho livro-apis-java, funciona basicamente como um id den- 
tro do sistema da Casa do Código. Ao contrário da nossa implementação, 
esse parâmetro vai como parte da própria URL, técnica conhecida como URI 
Template. 

E qual o motivo de passarmos o parâmetro de uma maneira diferente? 
Os motores de busca, tipo o Google, preferem endereços que, se acessados, 
sempre retornem o mesmo resultado. E esta é a diferença: quando usamos 
a ? estamos dizendo que basta uma mudança no valor do parâmetro que o 
resultado da página muda e, quando usamos o parâmetro como parte da URI, 
isso passa a ideia de que aquele é um endereço fixo. 

É muito simples aplicarmos essa mudança no nosso projeto. 


ORequestMapping(''/(idJ") 
public ModelAndView show(OPathVariable("id") Integer id){ 
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ModelAndView modelAndView = 

new ModelAndView('"products/show'!); 
Product product = products.find(id); 
model AndView.addObject ("product'!, product); 
return modelAndView; 


Usamos a notação (nomeDoParametro) para montar a URL com 
argumentos misturados. Além disso, temos que usar a annotation 
PathVariable para indicar o parâmetro do nosso método que deve ser po- 
pulado com a respectiva parte da URL. Caso tivéssemos agrupado os livros 
por categorias, poderíamos ter algo parecido com o que segue. 


//apenas um exemplo 


@RequestMapping("/{categoryId}/{productId}") 
public ModelAndView show(@PathVariable("categoryId") 
Integer categoryId, @PathVariable("productId") Integer id){ 


ModelAndView modelAndView = 

new ModelAndView("products/show"); 
Product product = products.find(id); 
modelAndView.add0bject("product", product); 
return modelAndView; 


Um detalhe importante é que os parâmetros de URL só podem ser asso- 
ciados com tipos considerados mais simples, por exemplo: 


e tipos primitivos 
e String 
e Date 


e Calendar 
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7.2 CARRINHO DE COMPRAS E O ESCOPO DE SESSÃO 


Agora, que já conseguimos navegar para a página de detalhe do livro, pode- 
mos começar a implementar a funcionalidade de adicioná-los ao carrinho de 
compras. Vamos apenas relembrar o trecho da JSP responsável por isso. 


<section class="buy-options clearfix"> 
<form action="<c:url value="/shopping'/>" method="post" 
class="container"> 
<input type="hidden" value="$fproduct.idJ" 
name="productId'/> 
<ul id="variants" class="clearfix"> 
<c:forEach items="$(product.pricesy! var="price"> 
<li class="buy-option"> 


<input type="radio" 

name="bookType" class='"variant-radio" 
id="$fproduct .id]-$fprice.bookType" 

value="$(price.bookType)" 

$fprice.bookType.name ()==?COMBO??ºchecked?:?? 

+ 


<label class='variant-label" 
for="$(product .id)-$fprice.bookTypeJ''> 
$fprice.bookType+ 

</label> 

<p class='variant-price'>$fprice.valuej</p> 

</li> 
</c:forEach> 
</ul> 


<input type="submit" class="submit-image icon-basket-alt" 
alt="Compre agora" 
title="Compre agora '$(fproduct.titlej'!" 
value="comprar'/> 
</form> 
</section> 


A URL que deve ser acessada é a /shopping e, além do ID do 
produto, precisamos saber qual o tipo de livro que o usuário pretende 
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comprar. Para isolar essa lógica, vamos criar um novo controller, o 


ShoppingCartController 


CController 
ORequestMapping("/shopping') 
public class ShoppingCartController { 


OAutowired 

private ProductDAO productDAO; 
GAutowired 

private ShoppingCart shoppingCart; 


ORequestMapping (method=RequestMethod.POST 

public ModelAndView add(Integer productId,BookType bookType)f 
Shoppingltem item = createItem(productId, bookType); 
shoppingCart .add(item); 
return new ModelAndView(''redirect: /produtos''); 


private ShoppingItem createItem(Integer productId, 
BookType bookType) 1 
Product product = productDAO.find(productId); 
Shoppingltem item = new ShoppingItem(product, bookType) ; 
return item; 


} 


Aqui não tem nenhum código que você já não tenha visto no livro: um 
controller normal, recebendo suas dependências injetadas e os métodos que 
tratam as requisições dos usuários. As classes novas são as que representam 
o carrinho de compras, no caso a ShoppingCart ea ShoppingItem, que 
representa o livro sendo adicionado no carrinho. Não vamos perder tempo 
dissecando a lógica dessas classes, vamos ficar atentos apenas às partes que 
estejam ligadas ao Spring. Caso queira conferir o código completo delas, basta 
acessar o endereço http://tinyurl.com/pajz3dh. 

É necessário avisar o Spring de que queremos injetar um objeto do tipo 
ShoppingCart em outros objetos do nosso código. 


@Component 
public class ShoppingCart { 
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Basta adicionar a annotation EComponent e, além disso, precisamos alte- 
rar a classe AppWebConfiguration e pedir que o pacote dessa classe passe 


a ser escaneado. 


CEnableWebMv c 

CComponentScan (basePackageClasses=(HomeController.class, 
ProductDAO.class,FileSaver.class,ShoppingCart.classj) 

public class ApphWebConfiguration { 


Adicionando produtos no carrinho 


Já podemos começar a adicionar os itens dentro do nosso carrinho e, por 
sinal, tudo parece estar correndo bem. O valor que está sendo impresso den- 
tro do nosso controller cresce a cada novo livro que é adicionado. Agora será 
feito um teste, vamos abrir uma nova página do seu navegador usando o fa- 
moso Private Browsing. Dessa maneira o navegador não salva nem reaproveita 


nenhuma informação que já existia previamente. 


e No Chrome, pressione Ctrl + Shift + N 


e No Firefox, pressione Ctrl + Shift + P 


Agora tente adicionar mais um livro ao carrinho e confira o valor im- 
presso. Provavelmente, apareceu o valor incrementado, como se só existisse 
um carrinho para todos usuários do site! Isso acontece porque, por default, 
o Spring mantém os objetos gerenciados por ele no escopo conhecido como 
Application. Ou seja, ele cria apenas uma instância e a reaproveita durante 
toda a execução do programa. Para ficar mais claro, você poderia fazer assim: 


CComponent 
GScope(value = WebApplicationContext.SCOPE APPLICATION) 
public class ShoppingCart { 
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O que necessitamos é de que exista uma instância do carrinho para cada 
sessão de navegação que existir naquele momento. Esse é o escopo mais co- 
nhecido como Session. 


CComponent 
GScope (value = WebApplicationContext.SCOPE SESSION) 
public class ShoppingCart { 


Mudar o escopo é muito simples, basta passarmos o valor que que- 
remos através da annotation @Scope. Outro escopo muito comum em 
aplicações web é o de Request, que você pode usar com a constante 
WebApplicationContext.SCOPE REQUEST. 

















Injetando objetos de escopos menores 


Caso você tenha tentado subir a aplicação, deve ter percebido que foi lan- 
çada uma exception com uma mensagem um tanto quanto grande. Vamos 
ver apenas uma parte dela. 


No thread-bound request found: Are you referring to request 
attributes outside of an actual web request 


A exception está nos informando de que estamos tentando usar um 
objeto de escopo relativo à web em outro objeto cujo escopo não tem 
nada a ver com a web. E é justamente o que está acontecendo, a classe 
ShoppingCartController não tem nenhuma anotação relativa ao escopo 
e, como já vimos, o default é o de Application. Nesta situação, o Spring 
não consegue resolver a injeção, pois um objeto de escopo de aplicação não 
tem nada a ver com os escopos web em si. A regra geral é: injete sempre obje- 


tos de escopos maiores em objetos de escopos menores, nunca ao contrário. 


e Objetos no escopo Application podem ser injetados em qualquer 
lugar. 


e Objetos no escopo de Session podem ser injetados em outros do 
mesmo escopo ou em escopo de Request. 
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Pensando nisso, a maneira mais fácil de resolver esse problema é modi- 
ficando a classe ShoppingCartController ea transformando em objeto 
de escopo de Request. 


CController 

ORequestMapping('/shopping'") 

GScope (value=WebApplicationContext .SCOPE REQUEST) 
public class ShoppingCartController 1 


A opinião deste autor é de que o Spring MVC falhou nesse quesito. Pen- 
sando em uma aplicação web, faz todo o sentido que os objetos que repre- 
sentam controllers sejam de escopo de requisição. Afinal de contas, essa é a 
natureza de uma aplicação web; objetos são criados e destruídos ao fim de 
uma requisição. Só que querer não é poder, então temos que nos adequar ao 
que o framework nos fornece. 

Como o escopo de Aplicação é muito comum em aplicações que usam 
o Spring, eles forneceram outra maneira de resolver o problema, bem mais 
obscura. 


CComponent 

OScope(value = WebApplicationContext.SCOPE SESSION, 
proxyMode = ScopedProxyMode.TARGET CLASS) 

public class ShoppingCart { 


Podemos usar o atributo proxyMode para indicar como os objetos ge- 
renciados devem ser criados. O modo default é criar uma instância normal, 
via reflection mesmo. Algo parecido com o que segue. 


Class klass = //recupera classe do objeto 
klass.newInstance(); 


E esse é justamente o motivo do problema, já que ele só vai poder criar o 
objeto do tipo ShoppingCart quando existir uma requisição web. Quando 





definimos o proxyMode iguala ScopedProxyMode.TARGET CLASS, esta- 
mos pedindo que o Spring modifique a maneira como ele cria o objeto, neste 
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caso usando uma biblioteca especializada nisso, chamada cglib. Usando 
esse artifício, conseguimos injetar um objeto de escopo menor, no caso de 


sessão, em um maior, no caso de aplicação. 





PROXY, UM DESIGN PATTERN 


O nome do atributo é proxyMode não por acaso. Ele avisa ao Spring 
que o Design Pattern Proxy deve ser aplicado para a criação dos objetos. 
Basicamente, a implementação desse pattern faz com que, em vez de tra- 
balharmos com o objeto alvo, neste caso o ShoppingCart, seja criada 
uma segunda classe que controla todo o acesso ao original. O próprio dá 
suporte à criação de um Proxy, só que ele impõe que sejam criadas in- 
terfaces para isso. Através da cglib, conseguimos a mesma implemen- 
tação, só que baseada na classe concreta. O Spring, como era esperado, 


suporta as duas maneiras. 











Entendo que usar o proxy é o jeito mais comum do mercado de atingir a 
injeção, mas neste caso continuo achando que colocar o escopo de request 
no controller é a solução mais limpa. Fique à vontade e decida qual solução 
se encaixa melhor no seu problema. 

Pronto, agora nossos usuários podem fazer suas compras sem que um 


coloque itens no carrinho do outro. 


7.3 EXIBINDO OS ITENS DO CARRINHO 


Na página de detalhe do livro, além de podermos colocá-lo no carrinho, tam- 
bém é possível exibir o número de itens que já existem atualmente. 


<ul class="clearfix"> 
<li><a href="" 


rel="nofollow">Seu carrinho ($fshoppingCart.quantity)) 
</a></1i> 
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</ul> 


Lembre-se que esse é mais um trecho da mesma página de deta- 
lhe, seu código completo você pode ver direto no Github, basta seguir 
este link: http://tinyurl.com/odjn4j3 


O problema aqui é que, sempre que a página de detalhe é acessada, o tre- 
cho que deveria exibir a quantidade de itens não exibe nada. 


Seu carrinho () 


A complicação aqui é que o Spring MVC está disponibilizando o objeto 
ShoppingCart com outro nome na Expression Language. 


$fsessionScope [?scopedTarget.shoppingCart'] .quantity) 


A chave criada foia scopedTarget .shoppingCart e, como tem um 
. (ponto) no nome, somos obrigados a acessar a chave através da sintaxe de 
mapa. Apenas por curiosidade, a variável com o nome sessionScope está 
sempre disponível nas JSPs para que que você tenha acesso diretamente ao 
mapa de variáveis que estejam neste escopo. O mesmo acontece com os obje- 
tos que estão no request, que ficam disponíveis através do SrequestScope. 
Só que a pergunta que não quer calar é: por que o Spring MVC colocou a 
variável começando com scopedTarget.? 

O problema foi justamente a nossa abordagem para resolver a injeção do 
carrinho de compras. Como foi escolhida a estratégia baseada no proxy, o 
framework coloca os objetos no escopo com esse prefixo, justamente para 
poder dar um tratamento diferenciado internamente. Caso tivéssemos op- 
tado pela abordagem de trocar o escopo do nosso controller pelo request e, 
não houvesse a necessidade de trocar a maneira como criamos os objetos do 
tipo ShoppingCart,o Spring MVC teria colocado na sessão a variável com 
o mesmo nome da classe e nossa JSP funcionaria tranquilamente. Lembre-se 
sempre que tudo é uma troca: quando decidimos ir por um caminho temos 
que ter em mente que, talvez, um preço seja cobrado. 
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De toda forma, agora nosso problema está resolvido. Caso não tenha gos- 
tado dessa abordagem, o que é completamente compreensível, podemos ten- 
tar outros caminhos. 


Expondo os beans na Expression Language 


Podemos ensinar ao Spring MVC que queremos que todos os nossos obje- 
tos gerenciados fiquem disponíveis para uso, através da Expression Language. 


public class AppWebConfiguration { 


0Bean 
public InternalResourceViewResolver 
internalResourceViewResolver() 1 
InternalResourceViewResolver resolver = 
new InternalResourceViewResolver(); 
resolver. setPrefix(''/WEB-INF/views/"); 
resolver. setSuffix(".jsp'); 
//essa linha expõe todo mundo 
resolver. setExposeContextBeansAsAttributes (true); 
return resolver; 


Com essa alteração o trecho S(shoppingCart) já vai funcionar. Ele 
vai usar o nome que está registrado dentro do container do Spring, que por 
default é o mesmo da classe. Essa solução até funciona, a única preocupação 
é se alguém começar a acessar tudo que é objeto a partir da JSP. 

Para restringir um pouco a fanfarra, pode-se liberar apenas alguns objetos 
para serem expostos. 


0Bean 
public InternalResourceViewResolver 
internalResourceViewResolver() { 
InternalResourceViewResolver resolver = 
new InternalResourceViewResolver(); 
resolver. setPrefix(''/WEB-INF/views/"); 
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resolver.setSuffix(".jsp'); 

//passamos o exato nome da classe que será registrada 
resolver.setExposedContextBeanNames ("shoppingCart'"'); 
return resolver; 


Dessa maneira, você pode controlar quais objetos devem estar sempre 
disponíveis. 


7.4 CONCLUSÃO 


Agora já conseguimos manter objetos em escopos diferentes e acessá-los nas 
nossas páginas. Neste momento do livro, você já tem ferramentas suficientes 
para começar a fazer sua mais nova aplicação! Não perca tempo, já comece 
a pensar no próximo projeto para praticar tudo que foi estudado até agora. 
Caso não esteja cansado, já leia o próximo capítulo, pois vamos fazer uma 
integração com um sistema externo, justamente para fechar o processo de 


compra do nosso usuário. 
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Retornos assincronos 


Nosso usuário já está quase fechando a compra dele. Agora, com os livros 
já colocados no carrinho, só falta que ele preencha os dados de pagamento e 
efetivamente compre os livros. Aqui, vamos apenas simplificar o processo e 
deixar que nosso usuário compre um livro apenas apertando um botão. 


<tbody> 
<c:forEach items="$(shoppingCart.listJ" var="item'!> 
<tr> 
<td class="cart-img-col"> 
<img src="! alt="${item.product.title}"/> 
</td> 
<td class="item-title"> 
$fitem.product.title) - ${item.bookType} 
</td> 
<td class="numeric-cell"> 
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$fitem.price) 
</td> 
<td class="quantity-input-cell"> 
<input type="number" min="0" readonly="readonly" 
value="$(shoppingCart . getQuantity (item)J!> 
</td> 
<td class="numeric-cell"> 
$fshoppingCart .getTotal (item)J 
</td> 
</tr> 
</c:forEach> 


</tbody> 
<tfoot> 
<tr> 
<td colspan="2"> 
<form 
action="$(spring:mvcUrl(ºPCicheckout?).build()J" 
method="post'"> 
<input type="submit" class="checkout" 
name="checkout" value="Finalizar compra " 
id="checkout'/> 
</form> 
</td> 


<td class="numeric-cell"> 
$fshoppingCart .total) 
</td> 
<td></td> 
bos 
</tfoot> 


Essa é a página onde nossos usuários poderão ver os itens adicio- 
nados ao carrinho. O nome dela é items.jsp e vai ficar na pasta 





WEB-INF/views/shoppingCart. Lembre-se que, para conferir o código 
completo, basta que você navegue até o repositório do projeto, https://github. 
com/livrospringmvc/lojacasadocodigo. Como é de praxe, nosso usuário não 
pode navegar diretamente para essa página, o endereço de acesso deve ser 
referente a um método na nossa classe ShoppingCartCont roller. 
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ORequestMapping (method=RequestMethod.GET) 
public String items(){ 
return "shoppingCart/items"; 


Todo o código presente nesse JSP é bem normal, não tem nada que 
não foi estudado até agora. O único detalhe novo é a presença do for- 
mulário de checkout, que aponta para o método checkout da classe 


PaymentController, exatamente o código que vamos começar a construir. 


CController 
ORequestMapping('/payment'!) 
public class PaymentController { 


GAutowired 
private ShoppingCart shoppingCart; 


ORequestMapping(value="checkout" ,method=RequestMethod.POST) 
public String checkout() { 
BigDecimal total = shoppingCart.getTotal(); 
//código de integração 
return 'redirect:/success"; 


É um controller comum, o único detalhe que vamos ter que implemen- 
tar agora é a integração com o meio de pagamento. Para deixar a aplicação 
mais real, foi criada uma aplicação web chamada book-payment, que está 
hospedada atualmente no Heroku. 

Caso queira efetuar um teste e estiver no Linux ou Mac, basta executar 
um curl. 


curl --header "Content-type: application/json" --request POST 
--data ’{"value": 600}? 
http://book-payment .herokuapp.com/payment 


A lógica é simples: só aceitamos pagamentos de até 500 reais. Somos 
obrigados a passar os dados usando o JSON, um formato de dados bastante 
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usado em aplicações que realizam integrações via HTTP. Caso o valor tenha 
seguido a regra, é retornado o status 201, que indica que um novo recurso 
foi criado, neste caso, o pagamento. Por outro lado, se tiver sido passado um 
valor maior que 500, é retornado o status 400, o que indica que a requisição 
possui dados inválidos. 


Rest Template 


Vamos precisar de uma biblioteca que nos ajude a realizar a requisição 
H'T'TP, para que nossa integração funcione. A lib mais famosa é a Http Com- 
ponents, que pode ser encontrada aqui http://hc.apache.org. 

Para não termos que lidar com os detalhes da biblioteca, vamos utilizar 
um objeto que já encapsula toda essa lógica. 


CController 
ORequestMapping('/payment'!) 
public class PaymentController { 


GAutowired 
private ShoppingCart shoppingCart; 
GAutowired 
private RestTemplate restTemplate; 


ORequestMapping(value = "checkout", 
method = RequestMethod.POST) 
public String checkout() { 
BigDecimal total = shoppingCart .getTotal(); 


String uriToPay = 
"http: //book-payment. herokuapp. com/payment"; 
try {d 
String response = 
restTemplate.postFor0bject (uriToPay, 
new PaymentData(total), String.class); 
return "redirect :/payment/success"; 
} catch (HttpClientErrorException exception) { 
return "redirect :/payment/error"; 
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O objeto do tipo Rest Template já disponibiliza diversos métodos, que 
podemos usar para realizar diversos tipos de requisições. Perceba que foi 
muito simples, apenas apontamos o endereço e invocamos o método que 
realiza o POST e espera como resposta uma simples String. Para conse- 
guirmos a injeção deste objeto, precisamos também alterar a nossa classe 
AppWebConfiguration para registrar o bean no container do Spring. 


CBean 
public RestTemplate restTemplate Of 
return new RestTemplate(); 


Outro detalhe que pode chamar a atenção é a utilização da classe 
PaymentData. Qual o motivo de necessitarmos dela? O sistema de paga- 
mento com que estamos realizando a integração pede que o formato do dado 
passado seja o seguinte: 


{"value": 600} 


É como se fosse um Map, precisamos de uma chave chamada value 
associada a um valor qualquer. Caso a gente passe o BigDecimal direto, 
qual seria o nome dessa chave? E justamente por isso que precisamos criar 


uma classe. 


package br.com.casadocodigo.loja.models; 
import java.math.BigDecimal; 
public class PaymentData { 

private BigDecimal value; 


public PaymentData() { 
} 
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public PaymentData(BigDecimal value) { 
this.value = value; 


public BigDecimal getValue() 1 
return value; 


Repare que temos um atributo que se chama exatamente value, justa- 
mente para que o Spring MVC possa pegar o objeto e gerar o JSON com 
as chaves corretas. 


Configurando o converter para JSON 


Neste momento, o nosso código de integração, se testado, lançará uma 
exception. 


org.springframework.web.client.RestClientException: 
Could not write request: no suitable HttpMessageConverter 
found for request type 
[br.com.casadocodigo.loja.models.PaymentData] 


O Spring MVC está nos dizendo que não conseguiu achar uma maneira 
de converter o objeto do tipo PaymentData para o JSON. Como já estamos 
vendo faz um tempo, ele é muito modular e, para tudo de que necessitamos, 
temos que ir adicionando as dependências necessárias. Nesse caso, precisa- 
mos adicionar uma biblioteca chamada Jackson, muita famosa no mundo Java 
no que diz a respeito à transformação de objetos em JSON. Precisamos reali- 
zar a alteração a seguir, no nosso arquivo pom.xml. 


<dependency> 
<groupld>com. fasterxml. jackson. core</groupld> 
<artifactId>jackson-core</artifactId> 
<version>2.5.1</version> 

</dependency> 
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<dependency> 
<groupld>com. fasterxml. jackson. core</groupId> 
<artifactId>jackson-databind</artifactId> 
<version>2.5.1</version> 

</dependency> 


Pronto, agora já conseguimos realizar a nossa integração sem maiores 
problemas! 


8.1 EXECUTANDO OPERAÇÕES DEMORADAS ASSIN- 
CRONAMENTE 


Agora que nosso código de integração já funciona, vamos tentar pensar um 
pouco adiante. A Casa do Código é uma empresa de sucesso, o Brasil in- 
teiro compra livros de tecnologia nela. Em certos momentos do ano, como 
na Black Friday, ela libera certas promoções que fazem com que o site fique 
muito movimentado e, com isso, temos muitos usuários concluindo compras 
ao mesmo tempo. Algo similar acontece em todas outras empresas. 

Não é raro, nessas situações de uso intenso, que os sistemas fiquem um 
pouco mais lentos ou até que caiam e fiquem fora do ar por um tempo, o que 
pode gerar um prejuízo grande. Em geral todos os sistemas têm seus pontos 
de gargalo e, como não poderia ser diferente, nós temos o nosso também. 
Já se perguntou quanto tempo pode levar para a nossa aplicação fazer uma 
requisição para o sistema de pagamento? Caso esse outro sistema demore, o 
que pode acontecer com o nosso site? 

Neste exato momento o funcionamento é basicamente o seguinte. 
Quando uma nova requisição chega no nosso Tomcat, ele faz um tratamento 
inicial e delega a responsabilidade para a Servlet configurada, nesse caso a do 
Spring MVC. A DispatcherServlet vai descobrir qual dos nossos con- 
trollers deve tratar a requisição e fazer o trabalho para que isso realmente 
aconteça. Todo esse fluxo, acontece dentro de uma Thread criada pelo Tom- 
cat, para que ele possa tratar várias requisições simultaneamente. Essa Thread 
só é liberada quando o método do nosso controller acaba de fazer o trabalho e 
indica para qual endereço devemos ir. Esse modelo de trabalho, onde alguém 
fica esperando o outro acabar, para aí sim continuar seu trabalho, é conhe- 
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cido como modelo síncrono. O problema desse modelo é que o Tomcat tem 
um número limitado de Threads que podem ser criadas e, caso esse número 
chegue no limite, as requisições dos nossos usuários vão começar a ser enfi- 
leiradas e podemos ter uma lentidão nas aplicações. 

Como já comentamos, em um pico de acesso, podemos sofrer deste pro- 
blema justamente no momento em que precisamos realizar a integração com 
um sistema externo, no qual não temos nenhum controle sobre o tempo de 


resposta. 


Indo para o assíncrono 


A grande sacada para esse tipo de situação é tentar liberar o Tomcat para 
atender outras requisições enquanto realizamos a integração com o nosso 
meio de pagamento. É exatamente para isso que, desde a versão 3 da espe- 
cificação, você pode criar uma Servlet que consegue trabalhar de modo as- 
síncrono! E, para a nossa sorte, a Servlet do Spring MVC já vem preparada 
para trabalhar desse jeito. 


ORequestMapping(value = "checkout", method = RequestMethod.POST) 
public Callable<String> checkout() 1 
return O -> { 
BigDecimal total = shoppingCart.getTotal(); 
String uriToPay = "http://localhost :9000/payment"; 
try { 
String response = 
restTemplate.postFor0bject (uriToPay, 
new PaymentData(total), String.class); 
return "redirect :/payment/success"; 
} catch (HttpClientErrorException exception) { 
return "redirect :/payment/error"; 


E 


Basta que retornemos um objeto do tipo Callable, que existe desde o 
Java 5 e é um análogo ao objeto tipo Runnable, muito comum para quem 
usa Threads. A única diferença do Callable é que ele nos permite dar um 
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retorno, algo necessário para nós, já que precisamos informar para qual en- 
dereço vamos depois da integração. Só de você retornar um Callable, o 
Spring MVC já vai criar iniciar um contexto assíncrono em sua Servlet e 
liberar para que o Tomcat possa usar a Thread dele para atender novas re- 
quisições. Assim, quando recebermos a resposta da integração, retornamos o 
endereço de redirect e o mesmo é informado para o Tomcat. Perceba que tudo 
ocorre de maneira bem transparente, não precisamos em nenhum momento 
lidar com a Servlet assíncrona em si, só precisamos estar cientes de que isso 
só é possível porque a especificação teve a preocupação. 

É importante notar que não estamos tratando da performance do nosso 
site, provavelmente o tempo de requisição vai ser o mesmo. O que estamos 
tratando aqui é da escalabilidade, estamos tentando manter o tempo médio 
de requisição mesmo que a aplicação sofra com um acesso acima do nor- 
mal. Você pode usar essa técnica para todo método do controller que tiver 
de realizar uma integração com um sistema que você não conhece. Um outro 
exemplo seria o envio de e-mail. 
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SINTAXE DO JAVA 8 PARA CLASSES ANÔNIMAS 


Usamos a sintaxe dos lambdas, disponível no Java 8, para retornar- 
mos um objeto do tipo Callable. Caso você esteja utilizando uma 
versão inferior do Java, pode trocar aquele código pelo seguinte: 


return new Callable<String>() { 
QUverride 
public String call() throws Exception { 
BigDecimal total = shoppingCart .getTotal (); 
String uriToPay = "http://localhost :9000/payment"; 
try É 
String response = 
restTemplate.postFor0bject (uriToPay, 
new PaymentData(total), String.class); 
return "redirect :/payment/success"; 
} catch (HttpClientErrorException exception) { 
return "redirect :/payment/error"; 


F 


Que era o comum, quando se fazia necessário o uso de classes anôni- 
mas. 











8.2 DEFFEREDRESULT E UM MAIOR CONTROLE SOBRE 
A EXECUÇÃO ASSÍNCRONA 


O uso do Callable éa maneira mais simples de realizar a execução de um 
código assíncrono dentro do nosso controller. Talvez o único ponto negativo 
é que você não tem nenhum controle de como esse código vai ser executado. 
Por exemplo: 


* Quantas novas Threads existem disponíveis para a execução do código 
assíncrono? 


* E se eu quiser controlar a criação das Threads? 
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* Eseeu precisar rodar esse código dentro de uma fila de processamento? 


Caso você se veja em algumas dessas situações, podemos usar o objeto 
do tipo DefferedResult que, em uma tradução livre, seria algo parecido 
como retorno postergado. 


ORequestMapping(value = "checkout", method = RequestMethod.POST) 
public DeferredResult<String> checkout() 1 


BigDecimal total = shoppingCart.getTotal(); 
DeferredResult<String> result = new DeferredResult<String>(); 


IntegrandoComPagamento integrandoComPagamento = 
new IntegrandoComPagamento (result, total, restTemplate); 


Thread thread = new Thread (integrandoComPagamento); 
thread.start(); 
return result; 


Respire, pois muita coisa aconteceu nesse código. Estou aqui justamente 
para explicar cada um dos passos. A parte principal é que criamos um objeto 
do tipo DefferedResult e o passamos como argumento para a construção 
de um outro objeto, que vai executar em uma Thread diferente e, em algum 
momento, vai sinalizar que acabou de realizar o processamento. Essa real- 
mente é a parte mais importante desse código. Sempre que você for trabalhar 
como DeferredResult,o objeto que foi retornado é o mesmo que vai ser 
passado como argumento para a execução em outra Thread. 

No código anterior, extraímos a integração com o meio de pagamento 
para uma outra classe, cujo código vai ser executado na Thread que criamos 
manualmente: 


package br.com.casadocodigo.loja.service; 
public class IntegrandoComPagamento implements Runnable { 


private DeferredResult<String> result; 
private BigDecimal value; 
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private RestTemplate restTemplate; 


public IntegrandoComPagamento (DeferredResult<String> result, 
BigDecimal value, RestTemplate restTemplate) { 
super(); 
this.result = result; 
this.value = value; 
this.restTemplate = restTemplate; 


QUverride 
public void run() { 
String uriToPay = "http://localhost :9000/payment"; 
try À 
String response = 
restTemplate.postFor0bject (uriToPay, 
new PaymentData(value), String.class); 
//linha de notificação 
result. setResult(''redirect: /payment/success"); 
} catch (HttpClientErrorException exception) { 
result. setResult(''redirect: /payment/error"); 


O método setResult é parte importante desse trecho de código. 


Quando você o invoca, o objeto do tipo DeferredResult notifica o 


SpringMVC de que o contexto assíncrono acabou e que ele pode gerar o re- 


torno para o usuário da aplicação. 


O uso do DeferredResult ainda permite um controle mais fino da 


execução assíncrona, disponibilizando alguns outros métodos que podem ser 


úteis. 
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* onTimeout (Runnable callback): registre um objeto que deve ter 


o método invocado caso expire um determinado tempo. 


e onCompletion (Runnable callback): registre um objeto que 


deve ter o método invocado quando a execução acabar. Por exemplo, 
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registrar um log. 


8.3 CONCLUSÃO 


Neste capítulo conseguimos realizar uma integração com um sistema de ter- 
ceiro e, para ficar ainda melhor, a integração pode ser feita sem travar o nosso 
servidor. Você deve levar essa lição para a sua vida, quando for realizar qual- 
quer tipo de operação que envolva um outro sistema que você não conhece; 
nunca fique faça nenhuma comunicação de maneira blocante. É uma pena 
que as APIs disponíveis no mundo Java já não sejam todas pensadas dessa 
maneira. Imagine se a especificação JDBC obrigasse todos os drivers a reali- 
zarem as consultas de maneira assíncrona, tudo seria muito melhor. 

Neste momento, meu conselho é que você descanse um pouco. Este ca- 
pítulo, apesar de não muito longo, envolveu conceitos não tão simples. Pense 
um pouco sobre eles e faça uns testes, tente ver onde esse tipo de solução po- 
deria se encaixar no seu atual trabalho. 
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CAPÍTULO 9 


Melhorando performance com 
Cache 


Sempre que entramos no site da Casa do Código, ela nos mostra um monte de 
livros que podemos comprar. O leitor mais atento já deve ter percebido que 
essa listagem não muda muito dentro de um determinado intervalo de tempo. 
E o fato de não mudar nos leva a um questionamento. Será que realmente 
precisamos ficar executando a lógica do método do controller em todas as 


vezes que um usuário acessar essa página? 
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9.1 (CACHEANDO O RETORNO DOS MÉTODOS DOS CON- 
TROLLERS 


Um dos pontos onde mais podemos ganhar em tempo de execução dentro 
de uma aplicação é justamente quando não necessitamos realizar a mesma 
lógica diversas vezes. Pensando em toda a arquitetura de uma aplicação web 
padrão, existem muitos lugares onde isso é possível. 


e Evitar acesso contínuo ao banco de dados; 


* Evitar que o navegador fique realizando requisições para arquivos es- 
táticos; 


e Evitar que um método do controller, cujo retorno não muda muito, 
fique sendo executado diversas vezes. 


Podemos atacar cada um dos pontos citados aqui, e olha que esses são os 
mais evidentes. Esse tipo de estratégia, onde guardamos um resultado e fica- 
mos reaproveitando, é comumente conhecido como Cache. Como já estamos 
acostumados, o Spring MVC também fornece ajuda nessa área. 

A ideia aqui é: queremos guardar o retorno do método, do controller res- 
ponsável por retornar o Model AndView relativo ao endereço de exibição dos 
livros cadastrados. Só para relembrar, dê uma olhada no código: 


CController 

OTransactional 
ORequestMapping("/produtos!!) 
public class ProductsController 1 


ORequestMapping (method=RequestMethod.GET 
public ModelAndView list(){ 
System. out .println("listando"); 
ModelAndView modelAndView = 
new ModelAndView("products/list''); 
modelAndView.addObject ("products", products.list()); 
return modelAndView; 
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Sempre que o usuário acessa o endereço /produtos, o Spring MVC in- 
voca esse método onde acessamos o banco e carregamos os livros cadastrados. 
Caso nossa página fosse inteiramente fiel à Casa do Código, teríamos ainda 
mais uma consulta, que retornaria os livros que são lançamentos. O grande 
ponto é que essas informações não mudam a cada acesso, logo não faz muito 
sentido ficarmos executando essa lógica o tempo inteiro. 


Para resolvermos isso, o Spring MVC provê uma solução muito simples. 


ORequestMapping (method=RequestMethod.GET) 
OCacheable 
public ModelAndView list 01 
ModelAndView modelAndView = 
new ModelAndView("products/list''); 
model AndView.addObject ("products", products.list 0); 
return modelAndView; 


Apenas colocar a annotation ECacheable em cima do método faz com 
o que o Spring MVC saiba que, uma vez que o código for executado, ele deve 
guardar o retorno e utilizá-lo para todas as próximas requisições que caiam 
no mesmo lugar. Agora já podemos tentar fazer um teste, para verificar se 
realmente o nosso método só está sendo executado da primeira vez. Só que 
quando tentamos levantar o servidor, aparece a seguinte exception: 


java. lang. IllegalStateException: No cache names could be detected 
on 'public org.springframework.web.servlet.ModelAndView 
br.com. casadocodigo.loja.controllers.ProductsController.list()º 


Essa exception não é muito clara. O módulo de cache do Spring pede que 
você defina nomes que podem agrupar um ou mais objetos que você decida 
colocar no cache. Por exemplo, todos os livros que ficarem no cache podem 
ficar agrupados sob a chave books. Isso também é conhecido como cache 
region. 


ORequestMapping (method=RequestMethod.GET) 
GCacheable (value="books'!) 
public ModelAndView list Of 

ModelAndView modelAndView = 
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new ModelAndView('"products/list'); 
model AndView.addObject ("products'!, products.list()); 
return model AndView; 


Essa é uma parte importante, quase sempre quando usarmos o 
ECacheable, vai ser necessário definir o valor para a região de cache. 

Pronto, agora podemos subir o servidor normalmente e, além disso, pre- 
cisamos verificar se o cache está funcionando. Para fazer essa checagem, po- 
demos acessar a tela de produtos mais de uma vez. O normal seria que a query 
realizada pelo Hibernate só fosse mostrada da primeira vez, indicando que o 
método list do nosso controller só executou no primeiro acesso. Só lem- 
brando, as queries estão exibidas porque fizemos essa configuração na classe 
JPAConfiguration. 

Caso você tenha realizado o teste, deve ter percebido que o método ainda 
continua sendo executado todas as vezes. 


Habilitando e configurando um provedor de Cache 


Vamos precisar habilitar o uso do cache, para que o Spring possa começar 
a guardar os retornos dos locais indicados com a annotation ECacheable. 


CEnableWebMvc 

CComponentScan (basePackageClasses=(HomeController.class, 
ProductDAO.class,FileSaver.class,ShoppingCart.classj) 

CEnableCaching 

public class AppWebConfiguration { 





Esse é justamente o papel da annotation GEnableCaching. Agora, de- 
pois de habilitado, no momento do start do servidor, outra exception é lan- 
çada. 


java. lang. IllegalStateException: No bean of type CacheManager 
could be found.Register a CacheManager bean or remove the 
EnableCaching annotation from yourconfiguration. 
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Perceba que ela nos informa que o Spring não foi capaz de encontrar ne- 
nhuma classe que seja responsável por efetivamente guardar os objetos que 
devem ser cacheados. A referência à interface CacheManager é importante, 
pois sempre que quisermos usar uma implementação que faça o papel do ca- 
che para a gente, teremos que buscar classes que implementem essa interface. 


public class ApphWebConfiguration { 
CBean 
public CacheManager cacheManager (){ 
return new ConcurrentMapCacheManager () ; 


Nesse código, fizemos uso da implementação mais simples, que já vem 
pronta dentro do próprio Spring, a Concur rentMapCacheManager. Nesse 
momento, ela é mais do que o suficiente para o que necessitamos. Caso não 
seja suficiente para o seu projeto, dê um pulo até o final do capítulo e já veja 
como podemos usar uma segunda opção. Com essas configurações, nossa 
aplicação já deve subir e conseguir guardar os objetos em cache! 


9.2 E QUANDO TIVEREM NOVOS LIVROS? 


Estamos mantendo no cache o retorno do método que lista os livros na Casa 
do Código. E quando fizermos o cadastro de um novo livro? O que deve 
acontecer com a listagem? Esse é um problema clássico do cache, em algum 
momento precisamos renová-lo. Usando a API de cache provida pelo Spring, 
não poderia ser mais fácil. 


ORequestMapping (method=RequestMethod.POST) 
GCacheEvict (value="books", allEntries=true) 
public ModelAndView save(...){ 





A annotation @CacheEvict tem justamente essa intenção. Podemos 
configurar que, quando algum método for invocado, determinada região do 
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cache deve ter seus valores invalidados. Usamos o atributo allEntries 





para indicar que queremos que todos os valores sejam retirados. Essa anno- 
tation suporta configurações mais específicas, entretanto, invalidar todos os 
valores geralmente vai ser mais do que o suficiente para a sua aplicação. Vale 
lembrar que o atributo value pode receber um array de nomes. Isso seria 
especialmente útil se tivéssemos cacheado o retorno do método que carrega 
um produto e o tivéssemos colocado em outra região, por exemplo. 


9.3 USANDO UM PROVEDOR DE CACHE MAIS AVAN- 
ÇADO 


O ConcurrentMapCacheManager, como já foi citado, é uma implemen- 
tação de cache muito simples. Vários fatores são importantes, quando vamos 
colocar objetos no cache. 


* Qualo tempo máximo? 
e Qual o número limite de objetos? 
e Qual o número limite de objetos de determinado tipo? 


* Qualo tempo máximo inativo? 


Claro que a resposta dessas questões dependem da complexidade do pro- 
blema que você está querendo resolver. Para tentar cobrir algumas dessas 
questões, podemos usar uma implementação provida pelo Guava, uma bibli- 
oteca criada pelo Google com várias classes que podem ser úteis em qual- 
quer projeto. Siga este link: https://code.google.com/p/guava-libraries/wiki/ 
GuavaExplained para mais detalhes sobre o que é oferecido. 

Para resolver o nosso problema, vamos ficar apenas com a parte de cache, 
fornecida pelo Guava. 


CBean 
public CacheManager cacheManager() 1 
CacheBuilder<0bject, Object> builder = 
CacheBuilder.newBuilder () 
.maximumSize (100) 
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.expireAfterAccess(5, TimeUnit.MINUTES); 
GuavaCacheManager cacheManager = new GuavaCacheManager(); 
cacheManager. setCacheBuilder (builder); 
return cacheManager; 


A classe CacheBuilder, do próprio Guava, serve para criarmos nossa 
configuração de cache. Perceba que conseguimos definir alguns valores 
que respondem a algumas das perguntas que fizemos anteriormente. Além 
disso, o Spring já criou uma extensão que possui uma implementação da 
interface CacheManager justamente para suportar o Guava, no caso a 
GuavaCacheManager. Com essa mudança, saímos de um provedor bem 
simples de cache para um já mais completo e que, provavelmente, você vai 
poder usar em algum de seus projetos. 

Apenas um último detalhe em relação à utilização do provedor do Guava: 
precisamos alterar nosso arquivo pom.xml para adicionar a extensão do 


Spring. 
<!-- cache --> 


<dependency> 
<groupId>com. google .guava</groupId> 
<artifactId>guava</artifactId> 
<version>18.0</version> 
</dependency> 


<dependency> 
<groupId>org.springframework</groupld> 
<artifactId>spring-context-support</artifactId> 
<version>4.1.0.RELEASE</version> 

</dependency> 


Além das opções citadas aqui no livro, o Spring também suporta outros 
provedores de cache, já prontos. 


e EhCache 


e GemFire 
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e JSR-107, especificação do Java para padronizar as APIs de cache. 


Caso nenhum desses sirva para você, ainda existe a possibilidade de você 


implementar a interface CacheManager e plugar a sua solução. 


9.4 CONCLUSÃO 


Neste capítulo, vimos uma das soluções mais importantes quando estamos 
falando de performance de uma aplicação. Evitar o acesso ao disco ou a algum 
serviço remoto, pode fazer com que sua aplicação diminua drasticamente o 
tempo de resposta das requisições. O único ponto a que você deve ficar muito 
atento é em relação a quais objetos devem ir para o cache. Lembre-se sempre, 
quando um objeto está cacheado, você deve aceitar que seus usuários, nem 
que seja por um curto período de tempo, podem ver dados que não são os 


mais atualizados. 
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CAPÍTULO 10 


Respondendo mais de um 
formato 


Nossa aplicação, até o presente momento, só lida com requisições vindas de 
um navegador, só que agora vamos um pouco além do que já existe na Casa 
do Código. Sites de vendas muito grandes, como a Amazon e o Submarino, 
além de exporem os seus produtos em seus sites, fazem parcerias com outros 
sites para que essas outras aplicações também possam exibir seus produtos. 


10.1 EXPONDO OS DADOS EM OUTROS FORMATOS 


Quando falamos de integração com outras aplicações, o primeiro ponto em 
que temos que pensar é: qual é o formato que vamos usar para realizar a in- 
tegração? Atualmente, nossa aplicação só é capaz de retornar páginas para os 
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clientes, no caso os navegadores, em HTML. Um outro tipo de cliente, hoje 
já muito comum, são os celulares com Android ou iOS. E como você já deve 
esperar, exibir dados através de HTML pode não ser o formato ideal para ser 
usado nesses aparelhos. 

A primeira tarefa que precisamos fazer é ter um outro método no nosso 
controller, que seja capaz de retornar a lista de livros em outro formato. O 
escolhido aqui vai sero JSON, que é um formato muito comum no mercado. 


public class ProductsController { 
ORequestMapping (method = RequestMethod.GET, value="json'"!) 
CResponseBody 
public List<Product> listJson() 1 
return products.list(); 


Perceba que só adicionamos mais um método à classe 
ProductsController, a única diferença foi que usamos a annota- 
tion EResponseBody. Ela informa para o Spring MVC que o retorno do 
método é para ser usado diretamente como corpo da resposta. Caso você não 
use essa annotation, ele vai procurar por uma página, que é o comportamento 
padrão. Basta que alguém acesse o endereço /produtos/json, que o 
retorno já vai ser um JSON. 

Talvez o leitor mais curioso esteja se perguntando: por que o retorno vai 
ser um JSON, onde foi que configuramos isso? Como já adicionamos a de- 
pendência do Jackson no nosso classpath, o Spring MVC já entende que esse 
é o único formato, além do HTML, cuja configuração já temos. 

E se tivermos clientes que trabalhem melhor com XML do que com JSON? 
Como vamos fazer? Nesse momento, temos que ter um método para cada 
formato de resposta que precisamos. 
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10.2 CONTENT NEGOTIATION E OUTROS VIEWRESOL- 
VERS 


Ter um método para cada formato de resposta diferente até funciona, o único 
problema é que você vai acabar com códigos repetidos. Lembre-se que o 
único ponto que vai mudar é a representação do retorno, a lógica para re- 
cuperar o dado vai ser a mesma. Vamos tentar resolver este problema. Pri- 
meiro, precisamos apagar aquele método novo e deixar apenas o antigo, que 
já adiciona a lista de produtos no ModelAndView. 


CController 
OTransactional 
ORequestMapping('/produtos'!) 
public class ProductsController { 
//apenas lembrando do nosso método que já existe. 


ORequestMapping (method=RequestMethod.GET) 
GCacheable (value="lastProducts!') 
public ModelAndView list Of 
ModelAndView modelAndView = 
new ModelAndView("products/list'); 
model AndView.addObject ("products", products.list()); 
return modelAndView; 


O ponto agora é: quando um cliente fizer o request para a URL 
/produtos, qual formato vamos retornar? Essa é a parte interessante, o pro- 
tocolo HTTP já fornece um jeito de lidar com esse problema! Ele permite 
que o cliente indique qual o formato de resposta que ele prefere. Segue um 
exemplo de requisição usando a ferramenta CURL, famosa no mundo Unix. 


curl -H "Accept:application/json!' -X GET 
"http://localhost :8080/casadocodigo/produtos" 


curl -H "Accept:text/html' -X GET 
"http://localhost :8080/casadocodigo/produtos" 
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No primeiro exemplo, fizemos uma requisição indicando que desejamos 
o retorno no formato application/json. Isso é feito através do cabeçalho 
Accept. Perceba que no segundo já indicamos que queremos HTML como 
formato. Essa técnica é conhecida como Content Negotiation e é muito uti- 
lizada em integrações baseadas no HTTP, também conhecida como REST. 

A parte bem legal é que o Spring MVC já oferece esse suporte para nós. 
Precisamos apenas ensiná-lo que agora ele tem que decidir qual formato re- 
tornar baseado no Accept. 


ContentNegotiatingViewResolver 


Para ensinar o Spring MVC sobre qual formato ele 
deve retornar, vamos usar um novo tipo de ViewResolver, o 


ContentNegotiatingViewResolver 


public class AppWebConfiguration { 


CBean 
public ViewResolver contentNegotiatingViewResolver( 
ContentNegotiationManager manager) { 
List<ViewResolver> resolvers = 
new ArrayList<ViewResolver>(); 


resolvers.add(internalResourceViewResolver (1); 
resolvers.add(new JsonViewResolver()); 


ContentNegotiatingViewResolver resolver = 

new ContentNegotiatingViewResolver(); 
resolver.setViewResolvers(resolvers); 
resolver. setContentNegotiationManager (manager); 
return resolver; 


Perceba que criamos uma lista com implementações de 
ViewResolver diferentes e depois criamos o objeto do tipo 
ContentNegotiatingViewResolver e passamos a lista. Basica- 
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mente, você pode criar o ViewResolver que você quiser, mas vamos ficar 
na realidade, retornar HTML, JSON e XML já vai ser suficiente, quase sempre. 


Outro detalhe importante é que, para lidar com páginas normais, apro- 





veitamos o método internalResourceViewResolver que já retorna o 
objeto responsável pelas JSPs. Já o responsável por tratar o JSON vamos ter 
que criar, pois o Spring MVC não disponibiliza um por padrão. 


package br.com.casadocodigo.loja.viewresolver; 


public class JsonViewResolver implements ViewResolver { 


QUverride 
public View resolveViewName (String viewName, Locale locale) 
throws Exception { 
MappingJackson2JsonView view = 
new MappingJackson2JsonView(); 
view.setPrettyPrint (true); 
return view; 


O importante é que devemos retornar um objeto do tipo View, que 
efetivamente será responsável por escrever a resposta no cliente. No nosso 
caso, estamos aproveitando a classe MappingJackson2JsonView, que 
já está disponível no projeto, desde que adicionamos as dependências do 
Jackson, no capítulo anterior. Como não vamos direcionar para nenhum 
arquivo, não é necessário o uso do parâmetro que indica o nome da 
view. Apenas como informação, existe um post no blog do Spring sobre 
este mesmo assunto, basta seguir o link: http://spring.io/blog/2013/06/03/ 
content-negotiation-using-views/. 

Pronto, agora o nosso mesmo método é capaz de retornar formatos dife- 
rentes em função do tipo. Para facilitar ainda mais, o Spring MVC já suporta 
que você defina o formato que você quer através da própria URL. Caso você 
queira forçar o retorno em JSON pelo navegador, basta que acesse a URL 
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com a extensão .json. Por exemplo, http://localhost:8080/casadocodigo/ 
produtos.json. O mesmo vale para HTML e outros formatos que você queira 
suportar. 


10.3 CURIOSIDADE SOBRE O OBJETO A SER SERIALI- 
ZADO 


O nosso método de listagem retorna um objeto do tipo ModelAndView, 
dentro do qual podemos adicionar quantos objetos quisermos para que sejam 
usados na view. Como que o serializador de JSON sabe qual destes objetos 
escolher? 

A maneira padrão é iterar por todas as chaves do Mode lAndView e gerar 
o JSON para cada um dos objetos encontrados. Caso você queira mudar 
isso, especificando uma determinada chave, é possível invocar um método de 
configuração. 


QUverride 

public View resolveViewName(String viewName, Locale locale) 
throws Exception { 
MappinglJackson2JsonView view = new MappingJackson2JsonView(); 
view.setPrettyPrint (true); 
//define a chave 
view. setModelKey ("products"); 
return view; 


Dessa forma, estamos forçando o MappingJackson2JsonViewaigno- 
rar as outras chaves. É importante notar que esse comportamento de analisar 
todos os objetos do ModelAndView não é o padrão. O serializador de XML, 
baseado na especificação do JAX-B, busca pelo primeiro objeto compatível! 


10.4 CONCLUSÃO 


Neste capítulo, foi abordado um tema que está em evidência: integração de 
sistemas via REST. Suportar o Content Negotiation é fundamental para você 
dar flexibilidade às aplicações clientes sobre qual formato elas preferem. Um 


148 


Casa do Código Capítulo 10. Respondendo mais de um formato 





outro ponto importante foi o uso da annotation EResponseBody, ela é 
muito útil quando você quiser que o retorno do método já seja o corpo da 
resposta. Só não ficamos com ela porque queríamos suportar o retorno em 
HTML e, para isso, tivemos que user o ModelAndView para indicar a página 
que deveria ser usada. 

Uma annotation que não abordamos, mas que também pode ser útil, é 
GRestController. Basta você colocar em cima do seu controller sempre 
que tiver uma classe onde todos os métodos devem usar o retorno direta- 
mente como corpo da resposta. Caso o nosso controller só retornasse JSON 
ou XML, podíamos ter feito isso e nos poupado de escrever GResponseBody 
em todos métodos. 
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Protegendo a aplicação 


Até agora, todas as URLs do nosso sistema estão acessíveis por todos os usuá- 
rios. Algumas até são liberadas, como a que leva para página inicial, que deve 
exibir todos os livros. Só que temos algumas URLs que necessitam de um 
usuário logado, como a que cadastra os novos livros e a de checkout. 

Podemos até implementar toda essa parte de segurança na mão, mas 
como já vem sendo feito no decorrer do livro, vamos usar um módulo do 
Spring que implementa boa parte do que a gente precisa. É bom sempre lem- 
brar que implementar uma estratégia de segurança não é trivial. Além de for- 
çar o login para algumas URLs, é necessário ter preocupação com pelo menos 
mais alguns itens. 


e Quais perfis podem acessar as URLs, também conhecido como autori- 


zação; 


e URLs acessadas por vários perfis, mas com trechos de página restritos; 
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e Fontes de dados diferentes para realização de login. 


11.1 CONFIGURANDO O SPRING SECURITY 


Para conseguirmos usar as classes do Spring Security, precisamos adicionar 
mais algumas dependências ao nosso projeto. Por isso, vamos alterar o ar- 
quivo pom.xml de novo. 


<dependencies> 
<!-— Spring security --> 


<dependency> 
<groupId>org.springframework. security</groupId> 
<artifactId>spring-security-config</artifactId> 
<version>4.0.0.M2</version> 

</dependency> 

<dependency> 
<groupId>org.springframework. security</groupid> 
<artifactId>spring-security-taglibs</artifactId> 
<version>4.0.0.M2</version> 

</dependency> 

<dependency> 
<groupId>org.springframework. security</groupId> 
<artifactId>spring-security-web</artifactId> 
<version>4.0.0.M2</version> 

</dependency> 

<dependency> 
<groupId>org.springframework. security</groupId> 
<artifactId>spring-security-core</artifactId> 
<version>4.0.0.M2</version> 

</dependency> 

</dependencies> 


<repositories> 
<repository> 
<id>spring-milestones</id> 
<name>Spring Milestones</name> 
<url>http: //repo.spring.io/milestone</url> 
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<snapshots> 
<enabled>false</enabled> 
</snapshots> 
</repository> 
</repositories> 


A versão estável do Spring Security ainda é a 3, mas já vamos usar a 4 
para garantir compatibilidade com os outros módulos que já estamos uti- 
lizando. Como a versão 4 ainda está em fase de construção, temos apenas 
acesso aos milestones. Por conta disso, fomos obrigados a adicionar mais 
um repositório, para que o Maven consiga buscar todos os jars necessários. 
Como o nosso projeto foi importado como Maven project, o classpath já é 
atualizado em função de cada alteração que fazemos no arquivo. Caso você 
tenha importado como projeto normal, lembre-se sempre de fazer um mvn 





clipse:zeclips 


Configuração do filtro 


Toda lógica de segurança do Spring Security é iniciada na classe 
FilterSecurityInterceptor, que é um filtro da especificação de Ser- 
vlets. Precisamos apenas configurar para que este filtro seja carregado. 


package br.com.casadocodigo.loja.conf; 
//imports 


public class SpringSecurityFilterConfiguration 
extends AbstractSecurityWebApplicationInitializert 


Aqui usamos a mesma estratégia da classe ServletSpringMVC. As 





duas, no fim, implementam a interface webApplicationInitializer, 
que é carregada pelo Spring para fazer o registro dos Servlets, filtros e tudo 
relativo à especificação de Servlets. Caso não se lembre, já comentamos sobre 
ela no segundo capítulo do livro. 

Só que, em vez de implementar diretamente a interface, herdamos da 
classe AbstractSecurityWebApplicationInitializer, que já vem 
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pronta no Spring Security e faz todo o trabalho de registro para a gente. 
Pronto, o filtro já está configurado! 


11.2 (GARANTINDO A AUTENTICAÇÃO 


Caso você tenha feito a configuração inicial e já tente navegar pela aplicação, 
vai perceber que todas as URLs ainda estão liberadas. O detalhe é que o filtro 
já está lá, mas não ensinamos nada para ele ainda. 


package br.com.casadocodigo.loja.conf; 
//imports 


CEnableWebSecurity 
public class SecurityConfiguration 
extends WebSecurityConfigurerAdaptert 


Aqui herdamos da classe WebSecurityConfigurerAdapter, que 
já fornece toda a infraestrutura pronta para começarmos a fazer nos- 
sas configurações de segurança. Além disso, utilizamos a annotation 





GEnableWebSecurity, que deve ser colocada em cima das classes de confi- 
guração do Spring Security responsáveis por efetivamente controlar as regras 
de acesso. Essa annotation faz com que outros componentes sejam carrega- 
dos. Seguem alguns exemplos. 


* SecurityExpressionHandler, responsável por avaliar a linguagem es- 
pecífica de controle de segurança, ainda vamos passar por ela. 


e WebInvocationPrivilegeEvaluator, responsável por verificar se os 
usuários tem acessos aos endereços. 


No fim, podemos fazer tudo isso na mão. O problema é que gastaríamos 
tempo configurando enquanto poderíamos estar resolvendo o problema da 
aplicação, que é controlar o acesso. Um último ponto necessário é informar 
que essa classe deve ser carregada quando nossa aplicação for iniciada. Vamos 
fazer isso na classe ServletSpringMVvC. 
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QUverride 
protected Class<?>[] getRootConfigClasses() { 
return new Class[]fSecurityConfiguration.class); 


OUverride 
protected Class<?>[] getServletConfigClasses() { 
return new Class[] fApphebConfiguration.class, 
JPAConfiguration.class+; 


Antes tínhamos usado o método getServletConfigClasses e agora 
fomos obrigados a usar o método getRootConfigClasses. O problema é 
que o filtro do Spring Security é carregado antes do Servlet do Spring MVC, 
logo, precisamos que os objetos de configuração relativos a ele estejam dispo- 
níveis antes. É justamente para isso que serve o getRootConfigClasses, 
ele faz com que as classes sejam lidas e carregadas dentro de um Listener 
que é lido quando o servidor sobe. No caso do Spring MVC, essa classe é 
a ContextLoaderListener. 

Agora, sem fazer mais nada, já adicionamos a necessidade de autenticação 
a todas as URLs. Caso algum usuário tente acessar qualquer endereço, ele vai 
ser redirecionado para uma tela de login. O único problema é: onde foi que 
criamos essas regras e de onde veio essa tela de login? 


Customizando as regras de acesso 


Como a gente não fez nada, o Spring Security usou o método 
configure, que já existe na classe WebSecurityConfigurerAdapter, 
para saber quais eram as nossas configurações de controle de acesso. 


protected void configure (HttpSecurity http) throws Exception { 
http.authorizeRequests () 
. anyRequest () .authenticated() 
«and () 
.formLogin() .and() 
“httpBasic(); 
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O objeto do tipo HttpSecurity é o ponto de entrada para que possa- 
mos customizar as regras de autenticação e autorização. Existem vários mé- 
todos sendo invocados nesse trecho de código, vamos só entender o fluxo 
um pouco mais. O método authorizeRequests () é o que nos retorna o 
objeto onde podemos configurar as regras de acesso em si. Logo após a sua 
invocação, dizemos que todo request ( anyRequest) tem que ser feito por 
alguém autenticado ( authenticated). O método formLogin indica que 
queremos que nosso sistema suporte autenticação baseada em um formulário 
comum. O último método, o httpBasic, indica que suportamos também 
o modelo de autenticação, de mesmo nome, provido pelo próprio protocolo 
HTTP. Fique atento ao método and (), ele serve para irmos voltando ao ob- 
jeto do tipo HttpSecurity, para que adicionemos as configurações neces- 
sárias. Ainda vamos mexer bastante nessa configuração, para darmos suporte 
a todas as nossas necessidades. 

Essa implementação é a que vem por default no Spring Security, como ela 
obriga todo request a ser autenticado, não conseguimos nem mais acessar a 
listagem de livros. 

Agora, antes de mais nada, vamos colocar as configurações necessárias de 
autenticação e autorização para nossos usuários. 


QUverride 

protected void configure (HttpSecurity http) throws Exception { 
http.authorizeRequests () 
.antMatchers('/produtos/form') .hasRole ("ADMIN") 
.antMatchers('/shopping/+*"') .permitAll() 
.antMatchers (HttpMethod.POST,'"/produtos!) .hasRole("ADMIN'!) 
.antMatchers('/produtos/+*"') .permitAll() 
. anyRequest () .authenticated() 
.and() .formLogin(); 


O código é quase que autoexplicativo. Vamos pegar alguns trechos para 
dar uma olhada. 


antMatchers('"/produtos/form') .hasRole ("ADMIN") 


Estamos dizendo que, além de estar logado, o usuário precisa ser ADMIN 
para acessar este endereço da nossa aplicação. Um outro caso interessante: 
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.antMatchers (HttpMethod.POST,'/produtos'!!) .hasRole("ADMIN'!) 


Caso o endereço /produtos seja acessado através do verbo POST, só 
liberamos acesso caso tenha sido disparado por um usuário com perfil AD- 
MIN. Um último que vale a observação: 


.antMatchers("/produtos/+x*'!) .permitAl1l (O) 


Aqui estamos dizendo que todos os outros endereços que comecem com 
/produtos estão liberados. O método antMatcher recebe uma expressão 
regular no mesmo estilo suportado pela ferramenta ANT, famosa no mundo 
Java na parte de builds. 

Após as configurações de URLs, informamos que todo o resto só está libe- 
rado caso o usuário esteja no mínimo autenticado. Fique atento para a ordem 
das invocações, ela é importante! Primeiro, faça as restrições e, depois, libere 
todo o resto. O Spring Security verifica as restrições na ordem em que elas 
foram cadastradas. Caso você adicione a regra que bloqueia tudo no início da 
configuração, todas as URLs ficarão bloqueadas. 


11.3 CONFIGURAÇÃO DA FONTE DE BUSCA DOS USUÁ- 
RIOS 


Os acessos às nossas URLs já estão devidamente configurados, entretanto, 
ninguém ainda consegue fazer o login na nossa aplicação. Precisamos en- 
sinar ao Spring Security de onde ele deve buscar os usuários para apli- 
car as nossas regras. Visando permitir implementar a busca da melhor 
maneira para cada aplicação, eles disponibilizaram uma interface chamada 
UserDetailsService. Vamos dar uma olhada em como vai ficar nossa 
classe de configuração depois de termos implementado a interface. 


CEnableWebSecurity 
public class SecurityConfiguration 
extends WebSecurityConfigurerAdaptert 


OAutowired 
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private UserDetailsService users; 


QUverride 
protected void configure (AuthenticationManagerBuilder auth) 
throws Exception { 
auth.userDetailsService(users). 
passwordEncoder (new BCryptPasswordEncoder ()); 


Perceba que vamos receber injetada justamente a implementação da inter- 
face que ainda vamos criar. Depois disso, usamos uma sobrecarga do método 
configure que recebe um AuthenticationManagerBuilder, objeto que 
nos permite associar um novo UserDetailsService ao Spring Security. 
Além disso, ainda forçamos que a senha seja mantida utilizando um algoritmo 
de hash; escolhemos o BCrypt. Poderiam existir vários capítulos somente de- 
dicados a algoritmos de hash, já que estes formam uma vasta área de estudo. 
Aqui no livro, vamos nos restringir somente a usar o BCrypt, que a própria 
documentação do Spring Security estimula que seja usado. 


Criando o nosso UserDetailsService 


No caso do nosso sistema, para recuperar um usuário através do login, 
vamos simplesmente criar um DAO. 


package br.com.casadocodigo.loja.daos; 
//imports 


CRepository 
public class UserDAO implements UserDetailsServicet 


OPersistenceContext 
private EntityManager em; 


QUverride 
public UserDetails 1loadUserByUsername (String username) 
throws UsernameNotFoundException { 
String jpql = "select u from User u 
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where u.login = :login"; 


List<User> users = em.createQuery (jpql,User.class) 
.setParameter("login", username) .getResultList(); 


if (users. isEmpty 0) 
throw new UsernameNotFoundException 
("O usuario "+username+" não existe"); 


} 


return users.get (0); 


Nosso método é bem comum: simplesmente realizamos uma query e de- 
vemos retornar um usuário encontrado, ou uma exception indicando o con- 
trário. Perceba que o nome do método é loadUserByUsername, justa- 
mente o que a interface nos obriga implementar. Uma outra questão interes- 
sante é que ele não recebe a senha como argumento, por que será? O principal 
motivo é para você não ter que lidar com o processo de aplicar o hash na se- 
nha antes de fazer a consulta. Você simplesmente busca pelo login e o Spring 
Security vai verificar se a senha cadastrada bate com a senha com que foi en- 
viada pelo formulário. 

Ainda em relação à assinatura do método 1loadUserByUsername, outro 
ponto que chama a atenção é o retorno. Ele nos força a retornar um objeto 
que implementa a interface UserDetails. E, se pensarmos bem, faz todo 
o sentido. Com o objeto que representa o usuário logado na mão, como o 
Spring Security ia saber qual era a senha dele? E quais perfis estão associados 
a ele? É para isso que serve a interface: para definir os métodos que ele poderá 
invocar e recuperar estas informações. 

Para satisfazê-lo, vamos criar nossa classe User e implementar a interface 
exigida. 


package br.com.casadocodigo.loja.models; 


//outros imports 
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import org.springframework.security.core.GrantedAuthority; 
import org.springframework.security.core.userdetails.UserDetails; 


CEntity 
public class User implements UserDetailsít 


@Id 

private String login; 

private String password; 

private String name; 

@ManyToMany (fetch = FetchType.EAGER) 

private List<Role> roles = new ArrayList<>(); 


//outros getters e setters 


@Override 
public String getPassword() { 
return password; 


@Override 
public Collection<? extends GrantedAuthority> 
getAuthorities() { 

return roles; 


@Override 
public String getUsername() { 
return login; 


@Override 
public boolean isAccountNonExpired() { 
return true; 


@Override 
public boolean isAccountNonLocked() { 
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return true; 


QOverride 
public boolean isCredentialsNonExpired() 1 
return true; 


OOverride 
public boolean isEnabled() { 
return true; 


Fomos obrigados a implementar até mais métodos do que estávamos es- 
perando, vamos dar uma olhada nos mais importantes para a gente. 


e getPassword: retorna o password do usuário; 
* getUsername: retorna o login do usuário; 


e getAuthorities: retorna os perfis do usuário autenticado. 


Os outros métodos são para um controle mais fino. O importante é: to- 
dos os métodos que retornam boolean devem retornar true para garantir o 
acesso do usuário às URLs protegidas. Caso o seu sistema precise controlar 
renovação de senha ou, por exemplo, bloqueio por inatividade, estes outros 
métodos podem ser úteis. 

Perceba que o método getAuthorities deve retornar uma lista de ob- 
jetos que implementam a interface GrantedAuthority. Essa é justamente 
a interface que nossa classe que representa o perfil deve implementar. 


package br.com.casadocodigo.loja.models; 


//outros imports 
import org.springframework.security.core.GrantedAuthority; 
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CEntity 
public class Role implements GrantedAuthority { 


@Id 
private String name; 


GOverride 
public String getAuthority O { 
return name; 


Pronto, com ambas as classes implementando a interface e sendo entida- 
des gerenciadas pela JPA, já podemos realizar efetivamente o login dos usuá- 
rios. Apenas para facilitar, você pode executar os inserts a seguir para cadas- 
trar usuários e seus perfis. 


insert into Role values(º?ROLE ADMIN?); 
insert into Role values(?ROLE COMPRADOR”); 


insert into User (login,name, password) 
values (º compradorOgmail.com”, 
“Alberto”, 


); 
insert into User (login,name, password) 
values ('adminOcasadocodigo. com.br” 
,’ Administrador”, 
); 


insert into User Role(User login,roles name) 

values (º comprador0gmail.com”,?ROLE COMPRADOR”); 
insert into User Role(User login,roles name) 

values ('adminOcasadocodigo.com.br”,?ROLE ADMIN?); 


Provavelmente, no seu sistema, você vai precisar cadastrar novos usuários 
através de um formulário. Para aplicar o hash na senha passada pelo formu- 





lário de cadastro, lembre-se de usar a classe BCryptPasswordEncoder. 
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Problema com a ordem de carregamento das configurações 


Caso você tente subir a aplicação, vai receber a seguinte exception: 


Caused by: org.springframework.beans.factory 
. NoSuchBeanDefinitionException: 
No qualifying bean of type 
[org.springframework.security.core.userdetails 
.UserDetailsService] 


Ela informa que não conseguiu achar nenhuma implementação para a in- 
terface UserDetailsService. O problema é que o DAO está configurado 
para ser carregado na classe AppWebConfiguration e ela só é carregada 
no momento de carregamento do Servlet do Spring MVC. 


OUverride 

protected Class<?>[] getServletConfigClasses() { 
return new Class[] fApphebConfiguration.class, 
JPAConfiguration.class+; 


Precisamos que ela passe para o método getRootConfigClasses para 
ser carregada no inicio da aplicação e já fazer com que os objetos fiquem dis- 
poníveis para serem lidos pelo filtro. 


QUverride 
protected Class<?>[] getRootConfigClasses() 1 
return new Class[]fSecurityConfiguration.class, 
AppWebConfiguration.class+; 


OUverride 
protected Class<?>[] getServletConfigClasses() { 
return new Class[] fJPAConfiguration.class+; 


Caso tente subir o servidor de novo, vai ver que felizmente o erro vai mu- 


dar. 
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Error creating bean with name 'userDAOº: Injection of persistence 
dependencies failed; nested exception is 

org. springframework. beans.factory.NoSuchBeanDefinitionException: 
No qualifying bean of type 
[javax.persistence.EntityManagerFactory] is defined 


Ele não consegue criar o objeto do tipo UserDAO, já que não sabe como 





criar uma EntittyManagerFactory. É o mesmo problema do caso an- 





terior: para criar o DAO, é necessária a criação do EntityManager, e o 
mesmo só é carregado no momento de criação do Servlet. Vamos fazer a úl- 
tima alteração nessa classe! 


QUverride 

protected Class<?>[] getRootConfigClasses() { 
return new Class []fSecurityConfiguration.class, 
AppWebConfiguration.class,JPAConfiguration.class+; 


QOverride 
protected Class<?>[] getServletConfigClasses() { 
return new Class [](%; 


Agora tudo é carregado no início, e com isso resolvemos esse problema 
chato da ordem de carregamento. 
Curioside sobre o prefixo ROLE | 


Talvez o leitor mais atento esteja se perguntando o motivo de cadastrar- 
mos os perfis com o prefixo ROLE . Para implementar as verificações de 
acesso, tanto de usuário autenticado quanto de autorizado, o Spring Security 
fornece uma interface chamada AccessDecisionVoter. A classe padrão, 
que faz a verificação dos perfis, éa RoleVoter. 


public class RoleVoter implements AccessDecisionVoter<Object> { 


private String rolePrefix = "ROLE "; 
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public boolean supports(...)í 
//verifica se deve aplicar verificações 


Perceba que ela força o uso do prefixo, é apenas uma decisão de pro- 
jeto. Imagine que você possa criar um AccessDecisionVoter customi- 
zado e associar outro padrão interno de perfil da sua empresa; como que o 
RoleVoter ia saber se devia aplicar a verificação ou não? É justamente para 
isso que ele força o uso do prefixo. Você agora deve estar imaginando outra 
coisa. Lá na configuração inicial, não foi bem assim que fizemos. 


.antMatchers("/produtos/form') .hasRole ("ADMIN") 


Onde está o prefixo? É que o método hasRole já adiciona para a gente. 


Assert.notNull (role, "role cannot be null"); 
if (role.startsWith("ROLE ')) 1 
throw new IllegalArgumentException( 

"role should not start with ’ROLE_’ 
since it is automatically inserted. 
Got ?" + role + "3; 

} 

String role = "ROLE_" + role; 


O método hasRole só existe por conta do RoleVoter. 


11.4 CROSS-SITE REQUEST FORGERY 


Agora que já conseguimos logar, podemos navegar entre as páginas do sis- 
tema. Um problema acontece na hora que tentamos, por exemplo, adicionar 
um produto ao nosso carrinho de compras. Quando clicamos no botão para 
realizar a ação, é retornado o status 403, indicando acesso negado. Ainda vem 
acompanhando da seguinte mensagem: 


HTTP Status 403 - Invalid CSRF Token ’null’ was found on the 
request parameter * csrfº or header ?X-CSRF-TOKEN”. 
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A sigla CSRF significa Cross-Site Request Forgery e é um tipo de ataque que 
pode ser feito contra sua aplicação. A ideia basicamente é que dados possam 
ser enviados para a nossa aplicação sendo provenientes de uma outra página 
qualquer, aberta no seu navegador. Como a Casa do Código é bem famosa, 
algum outro site poderia esconder um formulário na sua página e, quando um 
usuário que estivesse logado na Casa do Código interagisse com essa página 
externa, ela poderia submeter dados com um valor mentiroso para o endereço 
de checkout. Para conseguir mais informações, você pode acessar a página 
do próprio Spring Security, http://docs.spring.io/spring-security/site/docs/4. 
o.0.M2/reference/htmlsingle/gcsrf. 

Como foi falado no inicio do capítulo, segurança vai além de verificar lo- 
gin e perfis, e se proteger de ataques como esse faz parte do pacote. A prote- 
ção padrão contra o CSRF é feita através da geração de um número para cada 
usuário que se logue no sistema. A partir disso, todo POST que for feito deve 
ser acompanhado desse número, também chamado de token. Dessa forma, 
por mais que o site malicioso coloque um formulário escondido, o request não 
vai ser acompanhado do token, sendo automaticamente banido pela nossa 
aplicação. 

Para a nossa sorte, o Spring Security já provê a implementação para a 
proteção contra o CSRF. Talvez o leitor tenha percebido que a proteção já está 
ativada até para requests para URLs que não estão sob proteção. Por padrão, o 
Spring Security já gera o token a partir do primeiro request do usuário, para 
a aplicação que está fazendo uso do módulo. A consequência disso é que a 
verificação do CSRF já é feita para todo POST. Para adicionarmos o token, 
basta que adicionemos o parâmetro com o token nos nossos formulários. 


<form su? 
<input type="hidden" 
name="$( csrf.parameterName)! 
value="$( csrf.token)J!'/> 
</form 


A variável de nome _csrf contém a referência para um objeto do tipo 
DefaultCsrfToken. Através dele, temos acesso ao nome do parâmetro e 
ao valor atual do token. O nome nome da variável pode ser modificado, mas 
não é necessário nem que escrevamos o input em si. Podemos importar um 
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conjunto de taglibs do Spring Security que já possui a tag que gera o mesmo 
input. 


<hOtaglib uri="http://www.springframework.org/security/tags" 
prefix="security'" %> 


<form ...> 
<security:csrfInput/> 
</form> 


A segunda opção é bem melhor, já que não é necessário ficar lembrando 
do nome da variável e, muito menos, ficar correndo o risco de escrever errado. 
Caso você não esteja contente com nenhuma das duas, ainda podemos optar 
por uma terceira. 

Anotamos a classe de configuração do Spring Security com a annotation 
GEnableWebSecurity. Só que essa annotation carrega configurações im- 





portantes para uma aplicação web, mas não assume que estamos usando o 


Spring MVC como framework web. Podemos, em vez disso, começar a usar 





a annotation GEnableWebMvcSecurity. Ela carrega os mesmos compo- 
nentes da anterior e ainda adiciona configurações específicas para o projeto 
que utiliza o Spring MVC. Uma delas é adicionar o input do CSRF em to- 
dos os formulários construídos com a tag <form: form>. Nossa classe de 


configuração ficaria como o exemplo a seguir. 


CEnableWebMvcSecurity 
public class SecurityConfiguration extends 
WebSecurityConfigurerAdaptert 


Agora só precisamos trocar os nossos formulários. Vamos pegar o de adi- 
ção de um produto no carrinho, por exemplo. Atualmente, ele está assim: 


<form action="<c:url value="/shopping'/>" method="post" 
class="container"> 


</form> 
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Podemos substituí-lo pela tag de geração de formulário do Spring MVC. 


<form:form servletRelativeAction="/shopping" 
cssClass="container"> 


</form: form> 


Pronto, agora não precisamos mais nos preocupar em adicionar o input 
com o token do CSRF. De brinde, ainda não precisamos mais ficar usando a 








tag <c:url>. Quando utilizamos o atributo servletRelativeAction,o 
contexto da aplicação já é adicionado antes da URL! Lembre-se, é uma ótima 
prática usar as tags de formulário do Spring MVC, geralmente ela já vai fazer 
boa parte do trabalho padrão para você, como já vimos quando discutimos a 
validação. 


11.5 CUSTOMIZANDO MAIS ALGUNS DETALHES 


Até agora temos usado uma tela de login que tem sido gerada automatica- 
mente pelo próprio Spring Security. Só que, na nossa aplicação, precisamos 
ter a opção de criar uma tela com a cara da Casa do Código. E é claro que isso 
não vai ser um problema, basta ensinarmos ao Spring Security que a URL de 
login deve ser direcionada para um controller da nossa aplicação. 


CEnableWebMvcSecurity 
public class SecurityConfiguration extends 
WebSecurityConf igurerAdaptert 


QUverride 

protected void configure(HttpSecurity http) throws Exceptiont 
http.authorizeRequests () 
.antMatchers('/produtos/form') .hasRole("ADMIN!) 
.antMatchers('/shopping/+*"') .permitAl1() 
.antMatchers (HttpMethod.POST,'/produtos!!) 

“hasRole ("ADMIN") 

.antMatchers('/produtos/+*'') .permitAl1() 
. anyRequest () .authenticated() 
«and () 
.formLogin() .loginPage("/login").permitA11(); 
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O método formLogin() retorna um objeto do tipo 
LogoutConfigurer e, através dele, conseguimos trocar as configura- 
ções que vêm por default para a URL do formulário de login. Esse é o 
objetivo do método loginPage, ele recebe como argumento a URL que 
deve ser usada para ir para a tela de login. Devemos invocar o método 
permitAl1 para informar que esse endereço está liberado para todos os 
usuários. 


O JSP da tela podia ser parecido com o que segue: 


<h0 taglib uri="http://www.springframework.org/tags/form" 
prefix="form"y> 
<form: form servletRelativeAction="/login"> 
<div> 
<label> 
User 
<input type='text' name='username” value=""> 
</label> 
</div> 
<div> 
<label>Password 
<input type='password” name='password? /> 
</label> 
</div> 
<div> 
<input name="submit" type="submit" 
value="Login! /> 
</div> 
</table> 
</form:form> 


O nome dos parâmetros de login e senha também são definidos através do 
LoginConfigurer. O default é username para o login e password para 
a senha. A action do formulário está com o valor /login, que é a URL que, 
quando feito um POST, dispara o processo de login pelo filtro. O controller 
que leva para essa página fica por sua conta, leitor! 
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URL de logout e telas de erro 


Para habilitar um endereço que dispara o processo de logout da aplicação 
basta que invoquemos o método logout (). 


.formLogin() .loginPage('"/login') .permitAl1l() 

«and () 

.logout () .logoutRequestMatcher (new AntPathRequestMatcher( 
"/logout')); 


Por default, o Spring Security só libera que o logout seja feito através de 
POST, justamente para forçar a passagem do token do CSRF. Aqui fizemos um 
pouco diferente, por isso a invocação do método logoutRequestMatcher. 





A URL passada para ele pode ser acessada via GET e, mesmo assim, o processo 
de logout vai ser iniciado. 

Outro detalhe importante é a tela de acesso não autorizado. Ela acon- 
tece quando o usuário logado não tem o perfil necessário para acessar a URL, 
é o caso do cadastro de livros, só usuários administradores podem acessar. 
Quando um usuário tenta acessar uma URL dessas, o Spring Security gera 
um retorno com o status 403, que significa Not Authorized. Para customizar 
essa tela de erro, basta que façamos uso do arquivo web. xm1 da aplicação. 


<error-page> 
<error-code>403</error-code> 
<location>/WEB-INF/403. jsp</location> 
</error-page> 


Um detalhe interessante é que até agora não tínhamos precisado desse ar- 
quivo. Para quem não se lembra, ele é utilizado para fazermos diversas con- 
figurações relativas à nossa aplicação web, mas como quase tudo pode ser 
configurado via código ou annotation, ele está sendo usado cada vez menos. 
Para gerar o arquivo pelo Eclise, basta usar a opção Generate deployment 
Descriptor stub. 
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Profile As > 

Debug As > 

Run As > = 

Validate jurce 

Team » FF 

Replace With Ps search "E Console S$ irys 
Restore from Local History... 


[ContainerBackgroundProcessor[StandardEngine[ 
Maven FCantai nerRackaroundPracessorTStandardEnai neT 


” 
Java EE Tools > * Update EAR Libraries 
@ GitHub > ns 
Compare With > Lò Generate Deployment Descriptor Stub 


Fig. 11.1: Menu de geração de arquivo web.xml 


11.6 EXIBINDO O USUÁRIO LOGADO E ESCONDENDO 
TRECHOS DA PÁGINA 


Um detalhe comum é exibir o nome do usuário logado nas páginas que ele 
acessa dentro do sistema. Podemos fazer isso usando as taglibs disponibiliza- 
das pelo próprio Spring Security. Vamos alterar a página list. jsp: 


<h0 taglib prefix="security" 
uri="http://www.springframework.org/security/tags" %> 


<security:authentication property="principal" var="user'"/> 
01á ${user .name} 


A taglib authentication acessa o objeto do Spring Security que 
guarda o usuário que foi carregado pelo UserDetailsService. Ele imple- 
menta ainterface Authentication, que possuio método getPrincipal. 
Por isso, passamos o valor principal para o atributo property. Interna- 
mente, a taglib vai buscar pelo getter relativo à propriedade. Para poder- 
mos usá-lo no resto da página, exportamo-lo para a variável user. 

Ainda em relação a essa parte, sobrou um detalhe. Essa página pode ser 
acessada tanto por usuários logados como por qualquer anônimo. Caso acon- 
teça o último caso, neste momento, vamos receber um erro informando que 
a propriedade name não existe. Para resolver isso, vamos exibir esse trecho 
apenas para usuários logados! 
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<sec:authorize access='"isAuthenticated()'"!> 
<sec:authentication property="principal" var='user"/> 
<div> 
Olá $fuser .name) 
</div> 
</sec:authorize> 


Atag authorize serve justamente para exibir um trecho de página ape- 
nas se alguma condição for atendida. Nesse caso, estamos verificando se o 
usuário está logado. O atributo access recebe algumas expressões que são 
suportadas pelo Spring Security. Foi usada a isAuthenticated(), mas 
podiam ser várias outras. Outra muito comum é hasRole(...), que geral- 
mente é usada quando se deseja restringir certo trecho da página apenas para 
alguns perfis. 


<sec:authorize access="hasRole ("ROLE ADMIN?)'!> 
<li><a href="$(spring:mvcUrl(ºPCkform”) .build()J!'> 
Cadastrar novo produto</a> 
</1i> 
</sec:authorize> 


Para a lista completa, você pode acessar a documentação do Spring Se- 
curity. Caso precise, siga este link: http://docs.spring.io/spring-security/site/ 
docs/4.0.0.M2/reference/htmlsingle/gel-access. 


11.7 CONCLUSÃO 


Neste capítulo, vimos o suficiente do Spring Security para a maioria das apli- 
cações. Este é um dos melhores módulos do Spring e há ainda várias outras 
configurações possíveis. Outro ponto importante é que ele é bem extensível, 
talvez você se lembre das interfaces que foram mostradas durante o capítulo. 
Caso você precise de algum detalhe específico, pesquise primeiro dentro do 
framework antes de fazer uma solução caseira. 

Como o capítulo foi muito extenso, dê uma pausa para tomar uma água 
e processar tudo que você leu. Os próximos capítulos, apesar de importantes, 
são mais simples de serem entendidos. 
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CAPÍTULO 12 


Organização do layout em 
templates 


Já implementamos algumas das funcionalidades que existem dentro do sis- 
tema real da Casa do Código. Uma parte com que não nos preocupamos até 
agora é em relação ao layout da aplicação. Só que até mais importante que o 
layout é como vamos organizá-lo. Por exemplo, atualmente, entre as páginas 
que já implementamos, temos a de exibição do detalhe de um livro e a que 
exibe os produtos do carrinho de compras. Olhando com atenção para elas, 
vamos perceber que ambas possuem o mesmo header e footer. 


<header id="layout-header"> 
</header> 
<nav class="categories-nav"> 


Casa do Código 





Joas 
<!-- resto da página--> 
<footer id="layout-footer'"> 
aaen 
Aqui temos o problema clássico de repetição. Caso alguma mudança seja 
necessária nesses trechos, vamos ter que sair caçando em todas as páginas. 


Uma maneira comum de resolver essa situação é utilizando o sistema de in- 
cludes que já existe nas JSPs. 


<!doctype html> 
<!--[if 1t IE 7]><html class="no-js lt-ie9 lt-ie8 lt-ie7" 
lang="pt"> 
<! [endif] --> 
<!--[if IE 7]> 
<html class="no-js lt-ie9 lt-ie8" lang="pt"> 
<! [endif] --> 
<!--[if IE 8]><html class="no-js lt-ie9" lang="pt'><! [endif]--> 
<!--[if gt IE 8]><!--> 
<html class="no-js" lang="pt"> 
<!--<! [endif]--> 
<head> 
<meta charset="utf-8"> 
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> 
<meta name="viewport" 
content="width=device-width, initial-scale=i, 
maximum-scale=1"> 


<title>$(title)</title> 
</head> 


<body class="$fbodyClass+'> 
<h0include file="/WEB-INF/header. jsp" %> 


<!-- resto da página --> 
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<hôinclude file="/WEB-INF/footer.jsp" %> 


Até isolamos o header e o footer, só que sobrou esse inicio de declaração 
do HTML. E aí você pode pensar “não tem problema, é só criar mais uma 
include e isso também vai estar isolado”. Só que aí é que entra o problema: 
para uma pessoa nova montar uma página, seguindo o padrão do sistema, 
ela tem que saber de todas essa includes e ainda tem que saber a ordem! A 


tendência é só piorar. 


12.1 TEMPLATES 


Para amenizar esse problema, a especificação de JSP já pensou em uma solu- 
ção. A ideia é que possamos criar um modelo de página que possa ser utilizada 
por todas as outras páginas. 


<hOtaglib tagdir="/WEB-INF/tags" prefix="customTags"y> 


<customTags: pageTemplate> 
<section class="container middle"> 
<h2 id='cart-title'!'>Seu carrinho de compras</h2> 
<table id="cart-table"> 
<colgroup> 
<col class="item-col"> 
<col class="item-price-col"> 
<col class="item-quantity-col"> 
<col class="line-price-col"> 
<col class="delete-col"> 
</colgroup> 
<thead> 
<tr> 
<th class="cart-img-col'"'></th> 
<th width="65)"D>Item</th> 
<th width="10)">Preço</th> 
<th width="10%">Quantidade</th> 
<th width="104">Total</th> 
<th width="5)"></th> 
</tr> 
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</thead> 
<tbody> 


</customTags:pageTemplate> 


Ainda não se preocupe com a tag masterPage, vamos resolvê-la daqui 
a pouco. Vamos focar na estrutura da página. Não precisamos nos preocupar 
com muita coisa, apenas em adicionar uma tag que indica que queremos usar 
um modelo de página. A ideia é que essa tag defina o header, footer, outros 
trechos em comum e apenas receba como parâmetro o corpo da página espe- 
cífica. E se a equipe de front quiser reformular a estrutura da página e mudar 
a ordem dos menus, onde devemos mudar? Apenas no template! 





Perceba que importamos as tags apontando para uma pastaem WEB-INF. 
Diferente do que fizemos no capítulo de validação, vamos criar uma tag quase 
como se fosse uma JSP, também conhecida como Tag File. Nesse caso, 
vamos chamar a nossa tag de pageTemplate.tag. A especificação nos 
obriga a deixar os arquivos .tag dentro da pasta tags. 


<hOtaglib uri="http://java.sun.com/jsp/jstl/core' prefix="c"y> 
<hOtaglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt"%> 
<hO taglib 
uri="http://www.springframework.org/tags/form" prefix="form"y> 
<hOtaglib uri="http://www.springframework.org/tags" 
prefix="spring" %> 
<!doctype html> 
<!--[if 1t IE 7]> 
<html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="pt"> 
<! [endif] --> 
<!--[if IE 7]> 
<html class="no-js lt-ie9 lt-ie8" lang="pt"> 
<! [endif] --> 
<!--[if IE 8]><html class="no-js lt-ie9" lang="pt'><! [endif]--> 
<!--[5f gt IE 8]><!--> 
<html class="no-js" lang="pt'"> 
<!--<! [endif]--> 
<head> 
<meta charset="utf-8"> 


<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> 
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<meta name='"viewport" 
content="width=device-width, initial-scale=1, 
maximum-scale=1"> 


<title>Titulo da página</title> 
</head> 
<body class="classeDoBody"> 


<hôinclude file="/WEB-INF/header. jsp'" 4> 
<jsp: doBody/> 
<h0include file="/WEB-INF/footer.jsp" 4> 


</body> 
</html> 


É quase uma JSP, a única diferença é que ela pode ser reaproveitada como 
uma tag. Perceba que começamos o HT'ML e usamos as includes para deixar a 
página organizada. A grande jogada está no uso da tag <jsp:doBody>, ela 
que é a responsável por capturar o corpo passado como parâmetro e utilizá-lo 
dentro da nossa estrutura. 

Outro ponto importante é que toda página define um título e uma classe 
que deve ser usada na tag body. Como criamos uma tag, nada nos impede 
de declarar atributos para ela. 


<hOattribute name="title" required="true" Y> 
<h0attribute name="bodyClass" required="true" Y> 


<title>${title}</title> 


<body class="${bodyClass}"> 


<%@include file="/WEB-INF/header.jsp" %> 


177 


12.2. Deixando o template ainda mais flexível Casa do Código 





<jsp:doBody/> 


<h0include file="/WEB-INF/footer.jsp" 4> 
</body> 


Existem outras bibliotecas que podem ser usadas para a criação de tem- 
plates, como o Freemarker, Sitemesh, Tiles e Velocity e o Spring MVC tem 
integração com todas elas. O ponto é que a mesma funcionalidade já é su- 
portada pela JSP e, por esse motivo, este autor prefere ficar com o que já vem 
pronto na linguagem. 


12.2 DEIXANDO O TEMPLATE AINDA MAIS FLEXÍVEL 


Um detalhe com o qual é um pouco mais complicado de lidar é que certas 
páginas precisam de um trecho extra de Javascript logo antes do fechamento 
do body. Por exemplo, a página de listagem dos itens do carrinho exige que o 
seguinte trecho seja colocado: 


<script> 
$(function() { 
$(*gcheckout?).click(function() { 
-gaq.push([ ? trackPageview”, 
*/checkout/finalizaCompra” 1); 


H; 


$C .book-suggest’).click(function() { 
var book = $(this).data(’book’); 
_gaq.push([ ? trackEvent?, 'Recomendação”, 
'Livro?, book ]); 
H; 
DE 
</script> 


<script> 
$(function() { 
$C a[href^="http"]?’).not(? .dont-track’) 
.filter (function(index) { 
var ccb = $(this) .attr(ºhref?) 
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. index0f ("casadocodigo.com.br'); 
if (ccb == -1) 
ccb = $(this) .attr("href”).index0f ("localhost"); 


return ccb != 7 && ccb != 11; 
» .click(function(event) { 
var domain = this.href; 
domain = domain.substring(7); 
domain = domain.substring(0, domain. index0f(?/º)); 


if (domain.substring(O, 4) == ?www.)) 
domain = domain.substring(4); 


-gag.push([ * trackPageview”, '/LinkExterno/? + 
this.href 1); 
Es 
}; 
</script> 


Para contornar esse problema, podemos dizer que nossa tag pode receber 
fragmentos extras de páginas. 


<h0attribute name="title" required="true" Y> 
<h0attribute name="bodyClass" required="true" Y> 
<h0attribute name="extraScripts" fragment="true" %> 
<body class="${bodyClass}"> 

<h0include file="/WEB-INF/header. jsp" 4> 

<jsp: doBody/> 

<h0include file="/WEB-INF/footer.jsp" 4> 

<jsp:invoke fragment="extraScripts"/> 
</body> 


</html> 


Agora qualquer página que precise pode passar esse fragmento extra. 
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<customTags: pageTemplate bodyClass="cart" title="${title}"> 
<jsp:attribute name="extraScripts"> 


</jsp:attribute> 
<jsp: body> 

<!-- Resto do corpo da página--> 
</jsp: body> 


</customTags :pageTemplate> 


A tag <jsp:attribute> é utilizada para indicar o trecho que deve 
ser usado pela tag <jsp:invoke>. Você pode ter quantos fragmentos fo- 
rem necessários, tudo vai depender da complexidade do seu template. Ape- 
nas para completar, alguns detalhes importantes. Quando fazemos uso do 
attribute somos obrigados a usar a tag <jsp:body> para passar o corpo, 
não podemos mais deixá-lo livre. Um último ponto é a ordem: é necessário 
queo <jsp:body> seja a última. 


12.3 CONCLUSÃO 


Este capítulo foi bem rápido, apenas organizamos um pouco mais nosso 
layout. Não teve nada a ver com o Spring MVC em si. Mesmo assim é impor- 
tante, já que as telas compõem uma parte fundamental de qualquer aplicação. 
Não pare agora, já comece o próximo capítulo para que possamos fazer com 
que nossas telas falem diversas línguas. 
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CAPÍTULO 13 


Internacionalização 


Até este momento, todos os textos da aplicação estão escritos diretamente 
nas páginas. Por exemplo, vamos analisar o menu de navegação da include 
que contém o header do projeto. 


<ul class="container"> 
<li class="category"> 
<a href="http://www.casadocodigo.com.br'">Home</a> 
<li class='category'><a href='/collections/livros-de-agile!!> 
Agile </a> 
<li class="category"> 
<a href="/collections/livros-de-front-end">Front End</a> 
<li class='category'><a href=''/collections/livros-de-games'!> 
Games </a> 
<li class='category''><a href='/collections/livros-de-java"> 
Java </a> 
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<li class='category'><a href=''/collections/livros-de-mobile'!!> 
Mobile </a> 
<li class="category"><a 
href="/collections/livros-desenvolvimento-web'"> Web </a> 
<li class="category"> 
<a href="/collections/outros'> Outros </a> 


Todos os textos da aplicação estão escritos diretamente na página e, em 
geral, talvez isso não seja um problema. Entretanto, a Casa do Código já tem 
a sua versão internacional, a Code Crushing. Elas têm o mesmo layout e só 
mudam em uma coisa: todos os textos são escritos em inglês. 


13.1 ISOLANDO OS TEXTOS EM ARQUIVOS DE MENSA- 
GENS 


Caso continuemos com a estratégia de escrever os textos diretamente na pá- 
gina, teríamos que duplicar cada uma delas. Para conseguirmos internaci- 
onalizar nossa aplicação, vamos ter que isolar os textos no nosso arquivo 


properties. 


navigation.category.agile = Agilidade 
navigation.category.front end = Front end 
navigation.category.games = Jogos 
navigation.category.java = Java 
navigation.category.mobile = Desenvolvimento móvel 
navigation.category.web = Web 
navigation.category.others = Outros 


Mantivemos as chaves que já existiam lá e adicionamos as novas, referen- 
tes ao menu. A nomenclatura em um arquivo properties sempre é fonte 
de discussão. Aqui estamos seguindo o mais básico: dividimos os grupos com 
o . e usamos . para separar o nome do item em si. Agora que já isolamos 
os textos no arquivo messages, podemos usar as chaves nas nossas páginas 
e tags. 
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<hOtaglib uri="http://java.sun.com/jsp/jstl/fmt'" prefix="fmt"%> 
<hOtaglib uri="http://www.springframework.org/tags" 


prefix="spring" %> 


<nav class="categories-nav"> 


<ul class="container'"> 


ea 


<li 


<li 


ea: 


<li 


<li 


<li 


<li 


</ul> 


</nav> 


class="category"> 

<a href="http://www.casadocodigo.com.br'>Home</a> 

class="category"> 

<a href=!"/collections/livros-de-agile!!> 
<fmt:message key="navigation.category.agile'/> 

</a> 

class="category"> 

<a href="/collections/livros-de-front-end"> 
<fmt:message key="navigation.category.front'/> 

</a> 

class="category"> 

<a href=!"/collections/livros-de-games!'> 
<fmt:message key="navigation.category.games'/> 

</a> 

class="category"> 

<a href=!"!/collections/livros-de-java!!> 
<fmt:message key="navigation.category.java'!/> 

</a> 

class="category"> 

<a href="/collections/livros-de-mobile"> 
<fmt:message key="navigation.category.mobile'/> 

</a> 

class="category"> 

<a href="!/collections/livros-desenvolvimento-web"> 
<fmt:message key='navigation. category .web'/> 

</a> 

class="category"> 

<a href="/collections/outros!> 
<fmt:message key="navigation.category.others'/> 

</a> 


183 


13.2. Accept-Language header Casa do Código 





Perceba que usamos a tag <fmt :message>. O Spring já disponibiliza as 
chaves no contexto da JSTL para que possamos continuar usando a mesma 
tag. Outra opção seria usar a tag do próprio Spring. 


<spring:message code="navigation.category.agile'/> 


A diferença é que a tag do Spring já tem mais algumas opções, como o 
valor default e forma mais fácil de passar parâmetros. 


13.2 ACCEPT-LANGUAGE HEADER 


Até agora temos apenas o arquivo messages.properties com os tex- 
tos em português. Só que precisamos suportar as mensagens também em 
inglês. Para fazer isso, precisamos criar o arquivo com a extensão da lo- 
calização que queremos suportar. Por exemplo, podemos criar o arquivo 


messages en US.properties. 


shoppingCart.title = Shopping cart 


navigation.category.agile = Agile 
navigation.category.front = Front end 
navigation.category.games = Games 
navigation.category.java = Java 
navigation.category.mobile = Mobile 
navigation.category.web = Web 
navigation.category.others = Others 


Podemos também criar o arquivo com a extensão pt.properties, 
para suportar o português padrão. E agora a parte boa: não precisamos fazer 
mais nada! Basta que façamos a troca da língua padrão do navegador, que 
o arquivo correto vai ser escolhido. A pergunta que fica é: como o Spring 
descobre qual idioma o navegador prefere? 
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Fig. 13.1: Header com a opção de língua 


A resposta está no cabeçalho da requisição HTTP. Perceba que tem uma 
chave chamada Accept -Language e é nela que vêm as línguas prediletas do 
seu usuário. No caso do navegador do autor deste livro, está como português. 
Tanto que a primeira opção é o pt, mas caso nosso sistema não suporte esse 
idioma, ele fala que prefere o en-US. Carregar o arquivo de mensagens em 
função da língua do navegador é a maneira padrão de o Spring MVC lidar 
com a internacionalização. 


13.3 PASSANDO PARÂMETROS NAS MENSAGENS 


Outra situação muito comum no momento de exibir as mensagens interna- 
cionalizadas é a necessidade de que a mensagem seja construída dinamica- 
mente. Por exemplo, na página de listagem de livros, queremos dar boas- 


vindas ao usuário que acabou de logar no sistema. 


Olá $fuser .name) 


Vamos deixar inclusive essa mensagem internacionalizada. Para isso, va- 


mos acrescentar a entrada no arquivo de mensagens. 


users.welcome = Olá {0} 


Para representar os parâmetros, usamos os índices. Esta técnica já vem 
suportada por padrão no suporte à internacionalização presente no próprio 
Java. Agora, para usar na página, podemos usar a tag do Spring. 


<spring:message code="users.welcome'" arguments="${user .name}"/> 
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No atributo arguments passamos todos os valores que deverão substi- 
tuir os índices na mensagem. Caso tenhamos mais de um, podemos separá- 
los por ,. Para o mesmo processo ser feito usando a JSTL, teríamos algo 
parecido com o que segue: 


<fmt:message key="users.welcome"> 
<fmt:param value="$fuser.namey"/> 
</fmt :message> 


O primeiro modo é bem mais direto, por isso optamos por ele neste mo- 
mento. Lembre-se de adicionar as entradas nos arquivos das duas línguas 
pois, caso você busque por uma chave inexistente, com a tag do Spring, uma 
exception vai ser lançada. 


13.4 DEIXE QUE O USUÁRIO DEFINA A LÍNGUA 


Respeitar o idioma sugerido pelo navegador é uma ótima forma de tentarmos 
acertar a língua preferida pelo usuário. O problema dessa abordagem é se o 
idioma configurado não for realmente o preferido dele. Nesse momento, caso 
você esteja achando que todo mundo pode trocar isso facilmente, pense em 
todas as pessoas que você já conheceu que não tinham muito conhecimento 
de computação. Meu pai por exemplo, apesar de usar diariamente um nave- 
gador, não saberia como fazer essa troca. 

Uma estratégia adotada por alguns sites é a de oferecer links para que o 
próprio usuário possa definir o idioma predileto. 


Latin America 


TE Argantina Sports di Excador/ Engan ER damea /trçãr EE Puente ico | Engis 
BE Boms Engan als Ecuador Soaran EA amser Spaan EE Puente Rico / Speran 

= Umo DE Reçubtica Dammes / Ergash 
TE Ei Sahasor/ Spanish pubiica Domisica ; Sparsh 








Fig. 13.2: Bandeiras dos países 


Vamos adotar a mesma abordagem para a Casa do Código. Inicialmente, 
vamos adicionar os links para que o usuário possa escolher. Faremos isso no 
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arquivo header. jsp: 


<nav id="main-nav"> 
<ul id="clearfix"> 


<li> 


<a href="<c:url value="/produtos?locale=pt"/>"> 
Português 
</a> 
</li> 
<li> 
<a href="<c:url value="/produtos?locale=en_US"/>"> 
Inglês 
</a> 
</li> 
</ul> 
</nav> 


Já até passamos um parâmetro indicando os idiomas que queremos. A 
pergunta que fica é: quem vai receber esse parâmetro e trocar a língua prefe- 
rida? De novo, não precisamos nos preocupar, o Spring MVC já vem com o 


suporte pronto. 


public class AppWebConfiguration extends WebMvcConfigurerAdapter{ 


@Override 
public void addInterceptors (InterceptorRegistry registry) { 
registry.addInterceptor (new LocaleChangeInterceptor()); 


0Bean 
public LocaleResolver localeResolver (Of 
return new CookieLocaleResolver(); 
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O método 1ocaleResolver retorna uma implementação da inter- 
face LocaleResolver. No nosso caso, optamos por usar a estratégia 
que guarda o idioma preferido em um cookie. Existem outras, como a 





SessionLocaleResolver, que permite que a preferência fique guardada 
diretamente na sessão do usuário. Além disso, precisamos ensinar ao Spring 
MVC que ele deve trocar o valor da língua em função do parâmetro passado. 

Uma maneira padrão de fazer isso seria criando um GController. Só 
que, em vez de usar essa estratégia, vamos usar um interceptor já pronto, 
fornecido pelo Spring MVC. Interceptors funcionam como filtros, só que den- 
tro do framework. A ideia é que eles possam ser executados antes ou depois 
da execução de algum método dos nossos controllers. Uma aplicação comum 
deles é quando o programador decide fazer o processo de autenticação na 
mão. Como ele tem que verificar se o usuário está logado para toda requisi- 
ção, ele cria um interceptor para fazer essa checagem antes dos métodos dos 





controllers. No nosso caso, o LocaleChangeInterceptor verifica se foi 
usado o parâmetro locale na requisição e, em caso positivo, ele efetua a 
troca do idioma. Segue o seu código, apenas para curiosidade: 


public class LocaleChangeInterceptor extends 
HandlerInterceptorAdapter { 


/ 
* Default name of the locale specification parameter: "locale". 
*/ 
public static final String DEFAULT_PARAM_NAME = "locale"; 
private String paramName = DEFAULT_PARAM_NAME; 


public void setParamName (String paramName) { 
this.paramName = paramName; 


public String getParamName() 1 
return this.paramName; 
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QUverride 
public boolean preHandle(HttpServletRequest request, 
HttpServletResponse response, Object handler) 

throws ServletException { 


String newLocale = request .getParameter (this.paramName) ; 
if (newLocale != null) { 
LocaleResolver localeResolver = 
RequestContextUtils.getLocaleResolver (request); 
if (localeResolver == null) { 
throw new IllegalStateException 
("No LocaleResolver found: not 
in a DispatcherServlet request?"); 


} 
localeResolver.setLocale(request, response, 
StringUtils.parseLocaleString(newLocale)); 


} 
// Proceed in any case. 
return true; 


O método preHandler, como o próprio nome diz, é invocado antes da 
execução do nosso controller. Um ponto que deve ser lembrado é: a partir do 
momento em que o cookie do usuário foi setado, o Spring MVC sempre dará 
preferência a ele em detrimento do header Accept-Language. 


13.5 CONCLUSÃO 


Este capítulo também foi tranquilo. Internacionalização é um tema muito co- 
mum entre todas as aplicações, lembre-se apenas de não ser radical. Caso você 
não tenha planos de fazer outras versões, não se preocupe com este detalhe. 
Só o use se realmente for necessário, afinal de contas você está deixando de 
dar manutenção só em um lugar para dar em dois! Antes era apenas a página, 


agora é página e arquivo de mensagens. 
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Para o leitor mais esquecido, o carregamento do arquivo de mensagens já 
foi configurado bem no início do livro. 


CBean 

public MessageSource messageSource() { 
ReloadableResourceBundleMessageSource bundle = 

new ReloadableResourceBundleMessageSource(); 

bundle. setBasename("/WEB-INF/messages''); 
bundle. setDefaultEncoding("UTF-8''); 
bundle. setCacheSeconds (1); 
return bundle; 
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Testes automatizados 


Nosso sistema já está com as principais funcionalidades implementadas. Ca- 
dastramos e listamos os livros, adicionamos produtos ao carrinho de compras 
e até simulamos integração com um sistema externo. Podemos ainda adicio- 
nar mais coisas, como só listar os livros que foram aprovados, colocar livros 
em destaque, associá-los às respectivas categorias etc. Você já é capaz de im- 
plementar tudo isso. Um detalhe muito importante, que não foi tratado até 
este momento, é a parte de testes da nossa aplicação. Não queremos ficar ro- 
dando tudo manualmente para saber se as coisas estão funcionando. 
Existem algumas categorias de teste, geralmente divididas entre testes de 
unidade, de integração e de aceitação. A primeira categoria não vai ser abor- 
dada por este livro pois o Spring não tem nada de novo para oferecer nessa 
área. Você continuará usando o JUnit da mesma maneira como já deve ter 
lido em vários lugares. Em relação aos testes de aceitação, o Spring também 
não oferece nada de novo, você continuará trabalhando com ferramentas no 
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estilo do Selenium. Para uma base maior sobre a teoria relacionada a cada 
tipo de teste, aconselho o livro TDD no Mundo Real, do especialista e ótimo 
autor Maurício Aniche. 


14.1 TESTES DE INTEGRAÇÃO NO DAO 


A única categoria que sobrou foi a de teste de integração, mas não se engane: 
você vai passar uma boa parte do tempo trabalhando nele. Por exemplo, como 
saber se suas queries nos seus DAOs estão realmente funcionando? Geral- 
mente, os códigos que necessitam de alguma infraestrutura, por exemplo do 
acesso ao banco de dados, exigem que você faça bastante configuração e si- 
mule cenários, dos quais o seu framework já cuida para você. Para esses tipos 
de testes, o Spring pode lhe ajudar muito. 

Vamos começar adicionando um relatório na nossa aplicação. Precisamos 


saber o total vendido para cada tipo de livro. 


CRepository 
public class ProductDAO { 


OPersistenceContext 
private EntityManager manager; 


public BigDecimal sumPricesPerType(BookType bookType) 1 
TypedQuery<BigDecimal> query = manager.createQuery( 
"select sum(price.value) from Product p join 
p.prices price where price.bookType =:bookType", 
BigDecimal.class); 
query.setParameter ("bookType', bookType); 
return query.getSingleResult(); 


Por mais que você confie nas suas habilidades como programador, sem- 
pre é interessante saber se a consulta está funcionando como você espera- 
ria. Para verificar isso, podemos criar um teste que efetivamente cadastra 


alguns livros e verifica o retorno. Vamos criar a classe ProductDAOTest 


192 


Casa do Código Capítulo 14. Testes automatizados 





na mesma estrutura de pacote já existente, só que vamos colocá-la dentro do 


src/test/java. 


package br.com.casadocodigo.loja.daos; 
public class ProductDAOTest { 


OTest 
public void shouldSumAllPrices0fEachBookPerType Ot 
ProductDAO dao = new ProductDAO(); 


//salva uma lista de livros impressos 

List<Product> printedBooks = ProductBuilder. 
newProduct (BookType.PRINTED, BigDecimal.TEN) 
.more (4) .buildA11(); 

//£oreach do Java8, fique à vontade para usar um for 

//normal 

printedBooks.stream() .forEach(productDAO: : save); 


//salva uma lista de ebooks 
List<Product> ebooks = ProductBuilder. 
newProduct (BookType. EBOOK, BigDecimal.TEN) 
.more (4) .buildA11(); 
//£oreach do Java8, fique à vontade para usar um for 
//normal 
ebooks. stream() .forEach(productDAO: :save); 


BigDecimal value = 
dao. sumPricesPerType (BookType.PRINTED) ; 
Assert .assertEquals (new BigDecimal(50).setScale(2), 
value); 


Não se preocupe com a classe ProductBuilder, ela foi criada apenas 
para isolar a criação dos livros. Mais tarde damos uma olhada nela com mais 
carinho. O ponto importante é que salvamos alguns livros, depois invoca- 
mos o método que faz a soma das vendas e verificamos o resultado no final. 
Neste exato momento, o código não deve nem estar compilando, já que não 
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importamos o JUnit para nosso projeto. Basta que seja adicionada mais uma 


dependência no pom.xml. 


<dependency> 
<groupId>junit</groupId> 
<artifactId>junit</artifactId> 
<version>4.12</version> 
<scope>test</scope> 
</dependency> 


Com tudo configurado, já podemos rodar os testes. O problema é que na 


hora da execução recebemos um sonoro NullPointerl 





Exception. 





o DD o 


Failure Trace 


MEME Ms 


java.lang.NullPoi nterException 
at br.com.casadocodigo.loja.da 
at br.com.casadocodigo.loja.da 
at java.util.ArrayListãárrayListã 


at java.util.stream.ReferencePir 


at br.com.casadocodigo.loja.da 


Fig. 14.1: ProductDAO não recebeu o Entity Manager injetado 


O problema está dentro método save e não tem escapatória, o 


nosso EntityManager está nulo. Para o nosso DAO funcionar, um 








EntityManager deve ser injetado pelo Spring, só que fomos nós que instan- 


ciamos o objeto. Como o Spring vai controlar as dependências de um objeto 


se é o programador que o está criando? 
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O mais interessante nesse tipo de cenário é usar o próprio Spring e criar 
os objetos através dele. Inclusive, vamos ter que controlar a transação para 
garantir que os objetos sejam inseridos antes de executarmos as queries. 


OTest 
public void shouldSumAllPrices0fEachBookPerType() 1 
AnnotationConfigApplicationContext ctx = 
new AnnotationConfigApplicationContext( 
JPAConfiguration.class, ProductDAO.class); 
productDAO = ctx.getBean(ProductDAO.class); 


PlatformTransactionManager txManager = 
ctx.getBean(PlatformTransactionManager.class); 
TransactionStatus transaction = txManager 
.getTransaction(new DefaultTransactionAttribute()); 
//atê aqui foi configuração do spring 


List<Product> printedBooks = ProductBuilder 
.newProduct (BookType.PRINTED, BigDecimal.TEN) .more(4) 
.buildA1l11(); 

printedBooks.stream() .forEach(productDAO: : save); 


List<Product> ebooks = ProductBuilder 
.newProduct (BookType.EB00K, BigDecimal. TEN) 
.more (4) .buildA11(); 
ebooks .stream() .forEach(productDAO: : save); 
BigDecimal value = 
productDAO. sumPricesPerType(BookType.PRINTED); 
Assert .assertEquals (new BigDecimal(50).setScale(2), value); 


txManager. commit (transaction); 
ctx.close(); 


Não fique muito assustado com esse código, ele só demonstra um pouco 
do que acontece por trás dos panos quando você está utilizando o Spring 
MVC. Tivemos que criar o contexto do Spring na mão e também usamos os 
objetos dele para recuperar os objetos e controlar a transação. O ponto aqui 
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é: já temos muitas preocupações com nossos testes para ainda ter que ficar 
aprendendo a lidar com os detalhes internos do framework. Para não ficar 
preso nesse tipo de situação, o Spring criou um módulo focado apenas em 
ajudar nesses tipos de testes. 


Configuração do Spring Test 


Como já é de praxe, precisamos adicionar as dependências no pom. xml. 


<dependency> 
<groupId>org.springframework</groupId> 
<artifactId>spring-test</artifactId> 
<version>4.1.0.RELEASE</version> 
<scope>test</scope> 

</dependency> 


Agora vamos partir para realizar o mesmo teste, só que trocando aquele 
código pelas annotations providas pelo Spring Test. 


ORunWith (SpringJUnit4ClassRunner.class) 
CContextConfiguration(classes = 

(ProductDAO.class,JPAConfiguration.class+) 
public class ProductDAOTest { 


OAutowired 
private ProductDAO productDAO; 


OTransactional 
OTest 
public void shouldSumAllPrices0fEachBookPerType (1 
List<Product> printedBooks = ProductBuilder 
.newProduct (BookType.PRINTED, BigDecimal.TEN) 
.more(4) .buildA11(); 
printedBooks.stream() .forEach(productDAO: : save); 


List<Product> ebooks = ProductBuilder 


.newProduct (BookType. EBOOK, BigDecimal.TEN) 
.more(4) .buildA11(); 
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ebooks. stream() .forEach(productDAO: :save); 


BigDecimal value = 
productDAO. sumPricesPerType(BookType.PRINTED); 
Assert .assertEquals (new BigDecimal(50).setScale(2), 
value); 


Respire, vamos desvendar essas novas annotations. O código do teste 
ficou muito parecido com o inicial. A principal mudança é que agora re- 
cebemos o ProductDAO injetado e também podemos usar a já conhecida 
ATransactional para dizer que nosso método precisa rodar dentro de uma 
transação. 

A parte mais nova são as annotations que foram usadas em cima da nossa 
classe. A GRunWith é específica do JUnit e é fornecida para que frameworks 
possam ser notificados das fases de execução do teste. Por exemplo, a extensão 
do Spring Test é notificada da criação da instância do teste em si e, a partir 
disso, consegue fazer todas as injeções necessárias. E aí entra a outra per- 
gunta: quais classes devem ser carregadas? É justamente para isso que serve a 
annotation EContextConfiguration. Repare que passamos diretamente 
a classe Product DAO e além disso passamos a JPAConfiguration, que 
contém configuração de todos objetos necessários para utilizarmos a JPA. 

Um último ponto, que na verdade é o mais importante, é que nosso teste 
ainda está falhando. O problema é que estamos inserindo os produtos na 
tabela que vem sendo usada para desenvolvimento e lá, por consequência, já 
existem mais livros do que o planejado. 


14.2 UTILIZE PROFILES E CONTROLE SEU AMBIENTE 


Precisamos criar um ambiente específico para os testes, de forma que tenha- 
mos controle absoluto sobre o que existe no banco de dados, para uma ope- 
ração não atrapalhar a outra. A primeira ação que devemos realizar é a de 
criar um Datasource que aponte para outro banco de dados. Podemos criar 
uma classe de configuração só para isso, lembre-se que estamos trabalhando 
no source folder de testes. 
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package br.com.casadocodigo.loja.conf; 
//imports 
public class DataSourceConfigurationTest { 


CBean 
public DataSource dataSource (01 
DriverManagerDataSource dataSource = 
new DriverManagerDataSource(); 
dataSource.setDriverClassName(''com.mysql.jdbc.Driver''); 
dataSource.setUrl( 
"jdbc:mysql://localhost:3306/casadocodigo test''); 
dataSource.setUsername('root'); 
dataSource.setPassword("'"'); 
return dataSource; 


Agora basta que adicionemos esta classe na lista de classe carregadas: 


ORunWith (SpringJUnit4ClassRunner.class) 

GContextConfiguration(classes = 
(DataSourceConfigurationTest.class , 
ProductDAO. class, JPAConfiguration.classj) 


public class ProductDAOTest { 


Mesmo com essa alteração, quando rodamos o nosso teste, vemos que 
ele está com o mesmo problema do anterior. O resultado final ainda está 
sendo influenciado pelas tabelas usadas em ambiente de desenvolvimento. 
Só que nossa nova classe foi adicionada ao inicio na lista e, dessa forma, o 
Datasource configurado dentro da classe JPAConfiguration fica sendo 
o último a ser registrado. 

Claro, podemos trocar a ordem, mas não precisa nem pensar muito para 
saber que isso vai dar uma confusão grande. O que queremos é configurar 
que o Datasource de testes deva ser carregado em um contexto de testes 
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enquanto o outro deve ser carregado em ambiente de desenvolvimento. Para 
fazer isso, podemos usar o recurso de Profiles do Spring. 


public class DataSourceConfigurationTest { 


CBean 
OProfile("test'!) 
public DataSource dataSource ()1 
DriverManagerDataSource dataSource = 
new DriverManagerDataSource(); 
dataSource. setDriverClassName(''com.mysql.jdbc.Driver'"); 
dataSource. setUrl( 
"jdbc:mysql://localhost:3306/casadocodigo test"); 
dataSource. setUsername( "root" ); 
dataSource.setPassword( "" ); 
return dataSource; 


Agora, na classe JPAConfiguration, podemos dizer que o outro 
Datasource deve ser utilizado no ambiente de desenvolvimento. 


@Bean 
@Profile("dev") 
public DataSource dataSource(){ 
DriverManagerDataSource dataSource = 
new DriverManagerDataSource(); 
dataSource. setDriverClassName(''com.mysql.jdbc.Driver'"'); 
dataSource. setUrl( 
"jdbc:mysql://localhost:3306/casadocodigo"); 
dataSource. setUsername( "root" ); 
dataSource.setPassword( "" ); 
return dataSource; 


Por fim, no nosso teste informamos que o profile ativo é o de test. 


ORunWith (SpringJUnit4ClassRunner.class) 
GContextConfiguration(classes = 
(DataSourceConfigurationTest.class 
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,ProductDAO.class,JPAConfiguration.class)) 
GActiveProfiles("test'!) 
public class ProductDAOTest { 


Como o próprio nome informa, a annotation GActiveProfiles pode 
ser usada para indicar qual profile está ativo. Ela casa muito bem com a parte 
de testes, por isso vem dentro do Spring Test. Dessa forma, conseguimos 
deixar nosso teste passando! Além disso, já ganhamos um brinde: o Spring 
Test automaticamente limpa o banco de dados a cada teste. Isso já nos libera 
de ter que escrever este tipo de código e, além disso, não vamos ter um teste 


influenciando o outro. 
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ATIVE O PROFILE PARA A APLICAÇÃO WEB 


Neste exato momento, nossa aplicação web parou de funcionar. 
Como não definimos nenhum profile nela, o Datasource não conse- 
gue ser encontrado. Para consertamos isso, podemos configurar o profile 
através de um parâmetro que deve ser lido no inicio do servidor. Pode- 
mos fazê-lo na classe ServletSpringMVC. 


QUverride 
public void onStartup(ServletContext servletContext) 
throws ServletException { 
super .onStartup (servletContext) ; 
servletContext . addListener (RequestContextListener. class); 
servletContext. setInitParameter ("spring.profiles.active!, 
"dev'); 


Outra possibilidade seria fazer a configuração diretamente no 


web.xml. 


<context-param> 
<param-name>spring.profiles.active</param-name> 
<param-value>live</param-value> 
</context-param> 











14.3 TESTES DO CONTROLLER 


Testar os DAOs, além dos testes de unidades em si, já fornece uma boa confi- 
ança à nossa base de código. Afinal de contas, a maioria das aplicações é bem 
focada no uso do banco de dados. Outro componente que talvez valha a pena 
ser testado é o nosso controller. 

Geralmente, eles não vão possuir tanta lógica, basicamente vão controlar 
fluxos de chamadas para outros objetos. Mesmo sendo até certo ponto triviais 
de serem entendidos, alguns controllers não podem funcionar de maneira 
equivocada. Por exemplo, a URL de produtos deve sempre listar os livros 
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que estão no banco de dados, caso contrário a Casa do Código pode estar 
perdendo vendas. 


Os controllers são acessíveis através das URLs e para que isso funcione 
precisamos que o servidor esteja de pé. Este teste até pode ser feito e geral- 
mente é usada uma biblioteca como o Selenium para ajudar em todo o pro- 
cesso. O ponto negativo dessa abordagem é justamente precisar esperar todo 
o tempo de start do servidor. O Spring Test pode nos ajudar aí. Ele conse- 
gue montar o ambiente necessário para que consigamos acessar os controllers 
através das URLs, sem a necessidade de ter um servidor rodando. 


package br.com.casadocodigo.loja.controllers; 
//imports 


ORunWith (SpringJUnit4ClassRunner.class) 
CWebAppConfiguration 
CContextConfiguration(classes = { ApphebConfiguration.class, 
JPAConfiguration.class, SecurityConfiguration.class, 
DataSourceConfigurationTest.class }) 
GActiveProfiles("test'!) 
public class ProductsControllerTest { 
GAutowired 
private ProductDAO productDAO; 


OAutowired 
private WebApplicationContext wac; 


private MockMvc mockMvc; 


CBefore 
public void setupQ) { 
this.mockMvc = 
MockMvcBuilders.webAppContextSetup(this.wac) 


.build(); 
} 
@Test 
@Transactional 
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public void shouldListAllBooksInTheHome() throws Exception { 


this.mockMvc.perform(get (''/produtos")) 
. andExpect (MockMvcResultMatchers 
. forwardedUrl ("/WEB-INF/views/products/list.jsp')); 


A parte importante desse código é a simulação do request. Perceba que 
conseguimos fazer um get e dizer que esperamos que tenha sido gerado um 
forward para a JSP de listagem dos produtos. Por exemplo, podemos ir além 
e checar se efetivamente foi adicionada uma variável com nome products, 
para ficar disponível na página. 


this.mockMvc.perform(get ("/produtos")) 
. andExpect (modelAndViewMatcher) 
. andExpect (MockMvcResultMatchers 
.model () 
.attributeExists("products'!)) 
. andExpect (MockMvcResultMatchers 
. forwardedUrl("/WEB-INF/views/products/list.jsp')); 


Esse código é suficiente para fazer nosso teste passar. Vamos apenas 
analisar esse trecho um pouco mais, para entender melhor o que o método 





andExpect espera como argumento. 


Matchers 


ResultActions andExpect (ResultMatcher matcher) throws Exception; 





O método andExpect espera como parâmetro um objeto do tipo 
ResultMatcher, cujas implementações simplesmente fazem uma verifica- 
ção para a gente. São objetos desse tipo que são retornados pelos métodos 





attributeExists(...) ou forwardedUrl(...). 


public ResultMatcher attributeExists(final String... names) { 
return new ResultMatcher() 1 
QUverride 
public void match(MvcResult result) throws Exception { 
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ModelAndView mav = getModelAndView(lresult); 

for (String name : names) { 
assertTrue ("Model attribute °" + name + 
"> does not exist", mav.getModel () .get (name) 
I= null); 


+; 


Caso você precise de alguma checagem que não existe pronta, não fique 
acanhado, vá lá e crie o seu ResultMatcher. 


Objetos e annotations de configuração 


Voltando um pouco para o setup do teste, vamos dar uma olhada nos 
objetos e annotations necessários para fazer o nosso código funcionar. 


ORunWith (SpringJUnit4ClassRunner.class) 
CwWebAppConfiguration 
CContextConfiguration(classes = { ApphebConfiguration.class, 
JPAConfiguration.class, SecurityConfiguration.class, 
DataSourceConfigurationTest.class }) 
GActiveProfiles("test'!) 
public class ProductsControllerTest { 
OAutowired 
private ProductDAO productDAO; 


GAutowired 
private WebApplicationContext wac; 


private MockMvc mockMvc; 


CBefore 
public void setup0) { 
this.mockMvc = 
MockMvcBuilders.webAppContextSetup(this.wac) 
«build (); 
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Em relação às annotations, a única novidade é a 
ewebAppConfiguration. Ela é responsável por fazer o Runner do 
Spring Test carregar os objetos necessários para uma aplicação web, por 





exemplo, o HttpServletRequest eo HttpServletResponse. Além 
disso, precisamos criar o objeto responsável por simular os requests para 





nós, no caso o MockMvc. O objeto do tipo wWebApplicationContext é 
a representação do contexto do Spring para projetos web. Precisamos dele 
para montar o MockMvc, já que será necessário simular requests, response 


etc. 


Testes para garantir o controle de acesso 


Um último teste que podemos fazer é o que garante que só usuários com 
perfil de ADMIN possam acessar o endereço de cadastro de produtos. 


OTest 
public void onlyAdminShoudAccessProductsForm() 
throws Exception { 
RequestPostProcessor processor = 
SecurityMockMvcRequestPostProcessors 
.user ('"'compradorQgmail.com') .password('"123456") 
.roles ("COMPRADOR"); 
this.mockMvc.perform(get (''/produtos/form'') 
.with(processor)) 
. andExpect (MockMvcResultMatchers.status() .is(403)); 


Funciona basicamente no mesmo estilo do anterior, a única diferença é 
que usamos uma classe específica do módulo de testes do Spring Security. 
Pedimos para que seja criado um usuário com as características de que a 
gente precisa e tentamos acessar a URL protegida. Deve ser retornado o status 
403, informando que aquele usuário não tem autorização para acessar deter- 
minada URL. O objeto do tipo RequestPostProcessor pode ser usado 
quando precisamos adicionar alguma coisa ao request antes de ele ser proces- 
sado. É exatamente isso que é feito e um objeto que representa nosso usuário 
é adicionado, descartando a necessidade de termos que ir ao banco de dados 
fazer a busca. 
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Como quase sempre, vamos para as configurações finais. O filtro do 
Spring Security deve ser adicionado ao MockMvc para que ele possa inter- 
ceptar o request e aplicar as regras necessárias. 


CContextConfiguration(classes = { ApphebConfiguration.class, 
JPAConfiguration.class, SecurityConfiguration.class, 
DataSourceConfigurationTest.class }) 

GActiveProfiles("test'!) 

public class ProductsControllerTest { 


GAutowired 
private Filter springSecurityFilterChain; 


CBefore 
public void setup0) { 
this.mockMvc = 
MockMvcBuilders.webAppContextSetup(this.wac) 
.addFilters (springSecurityFilterChain) .build(); 


Recebemos injetado o filtro, já que ele é carregado através da nossa classe 
SecurityConfiguration eo adicionamos à simulação da nossa aplicação 
web. Para que essa parte funcione, precisamos adicionar mais uma dependên- 


cia ao nosso pom. xml. 


<dependency> 
<groupId>org.springframework. security</groupld> 
<artifactId>spring-security-test</artifactId> 
<version>4.0.0.M2</version> 
<scope>test</scope> 

</dependency> 


14.4 CONCLUSÃO 


Testar é uma parte essencial da nossa aplicação e os testes de integração têm 
um papel bem importante nisso. Com a ajuda fornecida pelo Spring Test, 
tudo fica muito mais simples, você tem que focar apenas na escrita do teste 


em si. 
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Outro ponto a ser lembrado deste capítulo é a utilização das annotations 
de profile. Elas são de grande ajuda tanto no cenário de testes quanto em rela- 
ção ao uso de objetos com ligação com o mundo exterior. Por exemplo, você 
não vai ficar querendo fazer upload de arquivos para a Amazon enquanto está 
em desenvolvimento e, para contornar isso, pode usar um profile que carre- 
gue um objeto que fique salvando no disco local. Existem várias aplicações, 
fique sempre atento. 
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Outras facilidades 


Já passamos por bastante coisa no decorrer do livro, mas para fechar com 
chave de ouro vamos ver mais facilidades providas pelo Spring que, com cer- 
teza, serão úteis no seu dia a dia de usuário do framework. 


15.1 RESOLVENDO O PROBLEMA GERADO PELO LAZY 
LOAD 


Não sei se você está lembrado, mas na hora da escrita dos métodos da nossa 
classe Product DAO usamos a expressão join fetch para ficar carregando 
a lista de preços relativas a um livro. 


public List<Product> list() { 
return manager.createQuery( 
"select p from Product p join fetch p.prices", 
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Product .class) .getResultList(); 


Só fazemos isso porque na nossa JSP tentamos carregar essa mesma lista. 
Olhe o código a seguir para refrescar a memória. 


<c:forEach items="${product.prices}" var="price"> 
[${price.value} - ${price.bookType}] 
</c:forEach> 


Caso você não utilizeo fetch join vai receber a seguinte exception: 


org.hibernate.LazyInitializationException: failed to lazily 
initialize a collection of role: 
br.com.casadocodigo. loja.models.Product.prices 


Ela informa que o Hibernate não conseguiu carregar a coleção de preços. 
Essa é a parte boa e ruim de usar um framework como o Hibernate. Quando 
você carrega seus objetos, ele substitui algumas propriedades para permitir 
que você programe de maneira orientada a objetos. Por exemplo basta invocar 
o método getPrices () que ele vai tentar disparar uma query no banco. O 
ponto ruim é que você precisa entender um pouco mais dele, para conseguir 





tirar proveito dessa funcionalidade. Basicamente, o EntityManager tem 
que ficar aberto durante todo o ciclo da requisição, inclusive no momento em 
que você está montando a JSP. 

Para facilitar nossa vida, o módulo do Spring de integração com a JPA e 
Hibernate já fornece um filtro, da API de Servlets, que faz esse trabalho para 
a gente. 


public class ServletSpringMVC extends 
Abstract AnnotationConfigDispatcherServletInitializer { 


QUverride 
protected Filter[] getServletFilters(O) { 
return new Filter[]f 
new OpenEntityManagerInViewFilter ()+; 
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Basta que façamos o registro do filtro que agora você pode invocar os mé- 





todos que você quiser, o EntityManager vai estar sempre aberto. Não es- 
tranhe que estamos criando o filtro na mão, desde a versão 3 da especificação 
de Servlets, podemos registrar quase tudo de maneira programática. 


Caso vocêtireo fetch join da consulta e acesse a tela de listagem de 
produtos, vai perceber que tudo acontecerá sem problema algum. Caso você 
seja um pouco mais curioso e analise o que saiu no console do servidor, verá 
algo como o exemplo a seguir. 


Hibernate: select prices0 .Product id as Product 1 0 0.,, 
prices0. .bookType as bookType2 1 0.,, prices0 .value as 
value3 1 0 from Product prices 


prices0. where prices0. .Product id=? 


Hibernate: select prices0 .Product id as Product 1 0 0 
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prices0. .bookType as bookType2 1 0.,, prices0 .value as 
value3 1 0 from Product prices prices0. where 


prices0. .Product id=? 


Hibernate: select prices0 .Product id as Product 1 0 0.,, 
prices0. .bookType as bookType2 1 0.,, prices0 .value as 
value3 1 0 from Product prices prices0. where 


prices0. .Product id=? 


Para cada produto carregado, o Hibernate fez uma query no banco para 
buscar os preços necessários. Esse é o problema das N + 1 queries causado 
pelo uso do Lazy Load. Na opinião deste autor, você deveria tentar planejar o 
máximo de queries que pudesse e deixar para usar o Lazy Load só em último 
caso. Inicialmente vai parecer que ele está ajudando muito, mas com o pas- 
sar do tempo você vai começar a perceber que muitas consultas estão sendo 
realizadas sem que você tenha controle. 
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15.2 LIBERANDO ACESSO A RECURSOS ESTÁTICOS DA 
APLICAÇÃO 


Continuando com as dicas de final de livro. Para montar as telas da nossa apli- 
cação, em alguns momentos, copiamos o HTML gerado pelo site da Casa do 
Código. Adicionamos o Spring Security na nossa aplicação e tudo continuou 
funcionando da maneira como deveria. Uma questão para pensarmos é: e se 
tivéssemos adicionado arquivos de Javascript e de CSS, o que aconteceria? 

Vamos fazer um teste simples. Vou criar um novo arquivo .js 
na pasta src/main/webapp/resources/js. Para simular uma si- 
tuação real, podemos criar o arquivo com o nome de jquery.js. 
Agora iniciamos o servidor e tentamos acessá-lo através da URL loca- 
lhost:8080/casadocodigo/resources/js/jquery.js. Você vai perceber que pron- 
tamente o Spring Security o direcionou para a tela de login. Para o framework, 
é apenas mais uma URL e, como não fizemos a configuração liberando o 
acesso a ela, somos bloqueados. 


Para resolver isso, vamos sobrescrever um outro método de configuração. 


CEnableWebMvcSecurity 
public class SecurityConfiguration extends 
WebSecurityConf igurerAdapterít 


QOverride 
public void configure(WebSecurity web) throws Exception { 
web. ignoring() .antMatchers('/resources/x*!'); 


Ao contrário do primeiro configure, que recebe como argumento um 
objeto do tipo HttpSecurity, esse recebe um WebSecurity. O primeiro é 
utilizado para fazer a configuração geral. Como vimos, ele faz muito mais coi- 
sas do que apenas permitir o acesso a algumas URLs. Este que estamos vendo 
agora é específico para a aplicação web. Por exemplo, estamos pedindo para o 
Spring Security ignorar qualquer acesso a URL que comece com resources. 
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Agora, quando você tentar acessa a mesma URL, o servidor vai retornar o 
status 404. O problema é que a Servlet do Spring MVC está achando que você 
está acessando um endereço mapeado para um controller, o que claramente 
não é o caso. Para resolver isso, vamos sobrescrever mais um método, agora 


na nossa classe AppWebConfiguration. 


OUverride 
public void configureDefaultServletHandling( 
DefaultServletHandlerConfigurer configurer) { 
configurer .enable(); 


Quando você invoca o método enable () na classe 
DefaultServletHandlerConfigurer, você está informando para 
o Spring MVC que, caso ele não consiga resolver o endereço, ele deve delegar 
a chamada para o Servlet Container em uso. Pronto, agora você já consegue 
servir os seus conteúdos estáticos. Lembre-se de deixá-los dentro de uma 
pasta específica, para ficar fácil de você configurar. 


15.3 ENVIANDO E-MAIL 


Uma última tarefa que você vai acabar precisando realizar é a de enviar e- 
mails. Quase todo sistema tem uma funcionalidade da qual enviar um alerta 
via e-mail é parte integrante. Como não poderia ser diferente, o Spring já vem 
com a abstração necessária para que possamos enviar um e-mail de forma 
simples. 

O sistema da Casa do Código, por exemplo, tem a situação ideal. Quando 
uma compra é realizada com sucesso, precisamos mandar um e-mail para o 


comprador. 


ORequestMapping('/payment'!) 
public class PaymentController { 


@Autowired 
private MailSender mailer; 


@RequestMapping(value = "checkout", 
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method = RequestMethod.POST) 
public Callable<ModelAndView> checkout ( 
OAuthenticationPrincipal User user) { 


return O) -> { 
BigDecimal total = shoppingCart .getTotal(); 
String uriToPay = 
"http://book-payment. herokuapp. com/payment"; 
try É 
restTemplate.postFor0bject (uriToPay, 
new PaymentData(total), String.class); 
//enviando email 
sendNewPurchaseMail (user); 
return new ModelAndView( 
"redirect :/payment/success"); 
} catch (HttpClientErrorException exception) { 
return new ModelAndView( 
"redirect :/payment/error"); 


p 


private void sendNewPurchaseMail(User user) { 
SimpleMailMessage email = new SimpleMailMessage(); 
email.setFrom("compras@casadocodigo.com.br"); 
email.setTo(user.getLogin()); 
email. setSubject ("Nova compra"); 
email.setText("'corpo do email"); 
mailer.send(email); 


Perceba que apenas recebemos um objeto do tipo MailSender, que é 
uma interface do Spring, e mandamos o e-mail. Mais simples, impossível. 


De brinde, ainda usamos a annotation GAuthenticationPrincipal, que 





permite que recebamos o usuário logado como parâmetro do nosso método. 
Pensando em design de código, poderíamos ter criado outra classe unica- 
mente responsável por enviar e-mails no sistema e tê-la usado no nosso con- 
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troller. Essa é uma tarefa que fica para você! 
Para o Spring conseguir fazer a injeção, precisamos ensinar-lhe qual im- 
plementação será usada. Para fazermos isso, mais uma vez, criaremos um 


método na nossa classe AppWebConfiguration. 


@Bean 
public MailSender mailSender() { 


JavaMailSenderImpl javaMailSenderImpl = 

new JavaMailSenderImpl (); 
javaMailSenderImp1.setHost ("smtp.gmail.com'); 
javaMailSenderImp1.setPassword("password"); 
javaMailSenderImp1.setPort (587); 
javaMailSenderImp1.setUsername("seulogin'"); 
Properties mailProperties = new Properties(); 
mailProperties.put ("'mail.smtp.auth'!, true); 
mailProperties.put ("mail.smtp.starttls.enable", true); 
javaMailSenderImpl.setJavaMailProperties(mailProperties); 


return javaMailSenderImpl; 


Os métodos são bem legíveis. A única coisa a mais, é a configuração do 
Properties. Alguns provedores de e-mail, como o gmail, vão pedir que 
você faça uma conexão em modo seguro, por isso a habilitação do Transport 
Layer Security(TLS). 

Para finalizar, como não poderia deixar de ser, vamos adicionar as depen- 
dências necessárias para que o Spring possa utilizar a especificação de e-mail, 
provida pelo próprio Java. 


<!-- email --> 


<dependency> 
<groupId>javax.mail</groupId> 
<artifactId>mail</artifactId> 
<version>1.4.7</version> 
</dependency> 
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15.4 CONCLUSÃO 


Essas últimas facilidades foram apenas para mostrar que, mesmo passando 
por muita coisa ao decorrer do livro, ainda tivemos mais detalhes para mos- 
trar. Tome bastante cuidado com a decisão de usar o Hibernate no projeto 
porque, por mais que ele abstraia muito da complexidade da persistência, ele 
vai exigir que você entenda mais a fundo o funcionamento dele, justamente 
para não cair nas armadilhas. Vimos também que é importante configurar 
nossos frameworks para que eles não bloqueiem nossos recursos estáticos, 
como Javascript e CSS. 

Não pare agora e já leia o próximo capítulo. Vamos fazer as configurações 
necessárias para realizar o deploy da nossa aplicação. 
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Deploy da aplicação 


Trabalhamos tanto durante o livro, que seria injusto você acabá-lo e não po- 
der mostrar para ninguém o que desenvolveu. Para resolvermos isso, vamos 
instalar nossa aplicação no Heroku, uma plataforma que suporta o deploy de 
aplicações das mais variadas linguagens. 


16.1 CONFIGURANDO O MAVEN PARA O HEROKU 


Ao contrário da maioria dos hosts, o Heroku não pede que você suba o ar- 
quivo .war da sua aplicação para o Tomcat ou Jetty dele. Em vez disso, é 
necessário usarmos uma outra versão do Tomcat, chamada de embedded. A 
diferença principal é que ele não suporta múltiplos contextos. Simplesmente 
o rodamos, pode até ser a partir de um método ma in e passamos a localização 


do nosso war. 
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java -jar target /dependency/webapp-runner. jar target/*.war 


O jar webapp-runner é que o vamos baixar para conseguir executar 
a versão minimalista do servidor. Vamos ensinar ao Maven que, quando ele 
for gerar o nosso arquivo de instalação, ele deve baixar o Tomcat embedded e 
copiar parao jar webapp-runner. jar. Para isso, vamos alterar o arquivo 


pom.xml. 


<dependencies> 
</dependencies> 


<build> 
<plugins> 


<plugin> 
<groupld>org.apache.maven.plugins</groupld> 
<artifactId>maven-dependency-plugin</artifactId> 
<version>2.3</version> 
<executions> 
<execution> 
<phase>package</phase> 
<goals> 
<goal>copy</goal> 
</goals> 
<configuration> 
<artifactItems> 
<artifactItem> 
<groupld>com. github. jsimone</groupId> 
<artifactId>webapp-runner</artifactId> 
<version>7.0.57.2</version> 
<destFileName> 
webapp-runner. jar 
</destFileName> 
</artifactItem> 
</artifactItems> 
</configuration> 
</execution> 
</executions> 
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</plugin> 
</plugins> 
</build> 


Adicionamos um plugin do Maven que realiza a cópia necessária para nós. 
Esse procedimento está também descrito na própria página do Heroku. Basta 
seguir o link: https://devcenter.heroku.com/articles/java-webapp-runner. 

Agora que o plugin está configurado, podemos pedir para o Maven gerar 
nosso war. 


caminhoInstalacaoMaven/bin/mvn package 


16.2 QUAL BANCO SERÁ USADO NO HEROKU 


Nesse exato momento, temos dos profiles para carregar o DataSource com 
os dados de conexão do banco de dados. Um para o ambiente de testes e outro, 
que é o default, para o ambiente de desenvolvimento. E para o ambiente de 
produção, qual banco vamos usar? Esse também é um caso que a parte de 
profile pode nos ajudar. 

O Spring permite que você crie uma variável de ambiente informando 
qual profile deve ser carregado pela aplicação. Outra maneira, mais simples, 
é passar um argumento na execução do programa, indicando que você quer 
deixar uma variável disponível, como se fosse uma de ambiente. Seguem as 
duas opções: 


SPRING PROFILES ACTIVE=prod 
java -jar target/dependency/webapp-runner. jar target/*.war 


java -jar -Dspring.profiles.active=prod 
target /dependency/webapp-runner. jar target/*.war 


É importante que você execute esses comandos em apenas uma linha. 

Definindo a variável, na hora de carregar o container, o Spring vai pro- 
curar por beans que estejam anotados com @Profile ("prod"). Para que 
tudo funcione, podemos criar outra classe de configuração que contenha ape- 
nas a versão do DataSource apontando para o outro banco. 
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OProfile("prod'!) 
public class JPAProductionConfiguration { 


OAutowired 
private Environment environment; 


CBean 
public DataSource dataSource() throws URISyntaxExceptiont 
DriverManagerDataSource dataSource = 
new DriverManagerDataSource(); 
dataSource. setDriverClassName("org.postgresql.Driver"); 


URI dbUrl = 
new URI (environment .getProperty ("DATABASE URL')); 
dataSource.setUrl ("jdbc:postgresql://" 
+ dbUrl .getHost() + ":" 
+ dbUrl .getPort () + dbUrl.getPath()); 
dataSource. setUsername (dbUrl . getUserInfo () 
.split(":")[0]); 
dataSource.setPassword(dbUr1.getUserInfo() 
.split(":")[1]); 


return dataSource; 


Eis um ponto que pode ter ficado na sua cabeça em relação ao banco 
usado para o ambiente de produção. O leitor mais atento deve ter notado que 
foi usado o PostgreSQL em vez do MYSQL. Fomos por este caminho apenas 
porque o Heroku usa o Postgre como default. De todo jeito, vale ressaltar que 
o melhor seria usar o mesmo banco em desenvolvimento e em produção. As 
informações de conexão foram extraídas da variável de ambiente fornecida 
pelo próprio Heroku. Segue um exemplo da formatação: 


export 
DATABASE_URL=postgres://user :password@localhost :5432/nomeDaApp 


Podemos acessar qualquer variável de ambiente através da classe 





Environment, já disponibilizada pelo próprio Spring. Através dela também 
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podemos saber em qual ambiente estamos rodando, por exemplo. 

Lembre-se que também precisamos adicionar essa nova configuração à 
classe ServletSpringMvc. A ideia é que ela será sempre carregada, só que 
vai ser usada apenas quando o profile de produção estiver ativo. 


public class ServletSpringMVC extends 
AbstractAnnotationConfigDispatcherServletInitializer { 


QUverride 
protected Class<?>[] getRootConfigClasses() { 
return new Class[] { SecurityConfiguration.class, 
AppWebConfiguration.class, 
JPAConfiguration.class, 
JPAProductionConfiguration.class }; 


16.3 NOVA APLICAÇÃO NO HEROKU 


Nossa aplicação já está devidamente configurada para ser deployada. Para 
finalizar, precisamos apenas criar uma nova aplicação no próprio Heroku. 

O Heroku faz todo processo de deploy ser baseado no git, de modo que é 
imprescindível que você o tenha instalado em sua máquina. Caso não o tenha, 
siga os passos aqui: https://help.github.com/articles/set-up-git/. Com o git 
configurado, acesse a pasta da sua aplicação e execute os seguintes comandos: 


git init 
git add -A 
git commit -m "versionando o código para deploy" 


O próximo passo é instalar o programa de linha de comando fornecido 
pelo Heroku. Para realizar o download siga os passos sugeridos neste link: 
https://toolbelt.heroku.com/. 
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Com o Heroku Toolbelt instalado, podemos criar uma nova aplicação. 
Rode o comando de dentro da pasta da sua aplicação, dessa forma o utilitário 
já vai configurar o seu repositório, fazendo com que ele aponte para o Heorku. 


heroku apps:create cdcspringmvc 


Essa linha é suficiente para ser criada uma nova aplicação. Tome apenas 
cuidado com o nome, porque ele pode já ter sido usado. Para finalizar a confi- 
guração, precisamos ensinar ao Heroku qual linha ele deve rodar para iniciar 
a nossa aplicação. Para isso, na raiz do projeto, temos que criar um arquivo 
chamado Procfile, com o seguinte conteúdo, e tudo na mesma linha: 


web: java $JAVA OPTS -jar -Dspring.profiles.active=prod 
target /dependency/webapp-runner. jar --port $PORT target/+.war 


O JAVA OPTS é apenas uma variável de ambiente definida pelo Heroku, 
cuja utilização é sugerida para subir a aplicação. 


Agora é a hora de ser feliz e subir o seu código! 


git push heroku master 


Pronto, você acabou de realizar o primeiro deploy no Heroku. Esta é uma 
vantagem grande dos Clouds, tudo já está configurado e automatizado do lado 
do servidor, basta que você se adeque um pouco e terá um deploy tranquilo. 


16.4 CONCLUSÃO 


Neste capítulo, estudamos um pouco do processo de deploy da aplicação. 
Ainda conseguimos ver um pouco mais de como a parte de profile pode nos 
ajudar. 

Duas lições de casa para você, apenas para deixar a aplicação ainda mais 
legal: é necessário que você crie um endereço para cadastro de novos usuários, 
para poder conseguir realizar o login da aplicação. Além disso, pode ser legal 
adicionar algum CSS para deixar o visual mais interessante. 
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Hora de praticar 


Muito obrigado por ter ficado comigo durante toda a jornada do livro! É 
muito importante que você tente praticar tudo que foi estudado. Tem chance 
de escolher a tecnologia do novo projeto? Não fique acanhado, use o Spring 
MVC e foque nas suas regras de negócio entregando muito mais valor para o 
seu cliente. Sem contar que, mesmo este ditado sendo velho, a prática leva à 
perfeição. Em cada novo projeto, você vai encontrar novos desafios que farão 
com que você entenda cada vez mais sobre o framework. 


17.1 MANTENHA CONTATO 


Eu estou completamente disponível para ajudá-lo onde for possível. Você 
pode me achar das seguintes formas: 
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Por e-mail, basta enviar uma mensagem para livros- 
pringmvcogmail.com 


Caso use o Twitter, é só acessar https://twitter.com/alberto souza 


Ainda há a possibilidade de acompanhar meus projetos pelo Github, 
basta acessar https://github.com/asouza. 


Caso queira postar uma dúvida e ainda ajudar outras pessoas, use o 
fórum criado especialmente para o livro, http://groups.google.com.br/ 
d/forum/livro-springmvc 


Vá além do conteúdo do livro e também acompanhe os posts feitos no 
blog https://domineospring.wordpress.com. 


Por último, todo e qualquer feedback sobre o livro é bem-vindo. Use o 


fórum ou mande diretamente para meu e-mail. Escrever o livro foi um grande 


desafio, espero que ele tenha sido de alguma valia para você. 
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